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Summary 


The  goals  of  Phase  I  of  SBIR  Contract  N00014-94-C-0081  are  to  design  in  detail  a  toolkit 
envinmment  based  on  formal  methods  for  the  specification  and  verification  of  distributed 
real-time  systems  and  to  evaluate  the  design.  The  evaluation  of  the  design  includes  inves- 
tigatkm  of  b<^  the  capability  and  potential  usefulness  of  the  toolkit  environment  and  the 
feanbility  its  implementation.  To  meet  these  goals,  we  have 

1.  Dengmsd  a  graphical  specification  language  based  on  ACSR  (Algebra  of  Communicat¬ 
ing  Shared  Resources)  and  develop  a  graph  attribute  grammar  of  the  language. 

2.  Designed  the  overall  implementatioa  structure  of  the  toolkit  environment  including  a 
m«iu-driven  graphical  user  interface,  a  graphical  composition  tool  for  specifications, 
analysis  tools  and  the  interface  between  the  components. 

3.  Evaluated  the  implementations  of  existing  graphical  specification  systems  to  see  whether 
they  can  be  used  without  major  chao|^  in  implementing  our  graphical  specification 
language. 

4.  Identified  state  minimiaation  algorithms,  analysis  techniques  (e.g.,  simulation),  and 
verification  techniques  (e.g..  equivalence  test,  state  exploration,  and  model  checking) 
that  we  plan  to  implement. 

5.  Identified  a  real-time  logic  and  a  model  checking  method  as  well  as  a  proof  system  for 
our  graphical  specificatioo  language. 

The  two  salkni  aspects  of  our  graphical  specification  language  are: 

1.  Its  semantics  is  precisely  the  same  as  that  of  ACSR. 

2.  It  includes  futures  specially  useful  for  scalability. 

Since  AC3R  has  a  well-defined  formal  semantics,  there  is  no  semantics  ambiguity  in  our 
graphical  specificatioo  language. 
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1  Introduction 

This  document  is  the  final  report  for  Phase  I  of  SBIR  Contract  N00014-94-C-0081.  It  includes 
the  results  of  Phase  I  as  well  as  a  brief  plan  for  Phase  II. 

The  result  reported  here  represents  an  important  development  for  implementing  a  graph¬ 
ical  toolkit  envircmment  based  on  a  formal  method  for  the  specification  and  verification  of 
distributed  real-time  systems.  Formal  methods  treat  system  components  as  mathematical 
objects  and  provide  mathematical  models  to  describe  and  predict  the  observable  properties 
and  behaviMs  of  these  objects.  Th«e  are  several  advantages  to  using  formal  methods  for 
the  specification  and  analysis  of  real-time  systems.  They  include  ( 1 )  the  early  discovery  of 
ambiguities,  inconsistencies  and  incompleteness  in  informal  requirements;  (2)  the  automatic 
OT  machine-assisted  analysis  of  the  correctness  of  specifications  with  respect  to  requirements; 
and  (3)  the  evaluatkm  of  design  alternatives  without  expensive  prototyping. 

As  computers  become  ubiquitous,  they  are  increasingly  used  in  mission  critical  environ¬ 
ments.  In  particular.  Navy  systems  rely  increasingly  on  real-time  software  to  accomplish 
their  intended  pjals.  Typical  mission  critical  iqrplications  are  control  systems,  monitoring 
qrstems  and  communication  systems.  Any  failure  of  such  computer  systems  may  cause  a 
great  financial  loss,  environmental  disaster  or  even  the  loss  of  lives.  Potential  high  cost 
associated  sritb  an  incorrect  operation  of  these  systems  has  created  a  demand  for  a  rigor¬ 
ous  framework  in  which  various  design  alternatives  can  be  formally  specified  and  rigorously 
analysed  and  tested  before  implementation. 

It  is  commonly  believed  that  future  critical  systems  will  be  mote  complex  due  to  increased 
demands  on  their  functknialitics  as  well  as  the  size  of  the  problem  domain.  Thus,  it  will 
be  difficult  to  analyze  and  test  correctness  without  computer-aided  tools.  In  addition,  these 
systems  are  costly  to  prototype,  requiring  careful  prediction  of  timing  properties  before 
implementatioo  and  evaluation  of  design  alternatives.  Thus,  it  is  important  to  develop  a 
formal  fraiMwm'k  that  supports  automatic  and  computer-aided  anal>*sis  as  well  as  scalable 
spedficatioos  to  effectively  cope  with  incr^sed  complexity. 

There  has  beoa  significant  progress  in  the  devdopment  of  real-time  formal  methods 
[36.  16,  32.  27.  26.  3.  9.  39.  2.  21.  10.  U.  12.  29.  28.  3T.  22].  Much  of  this  work  falls 
into  the  traditional  categories  (rf  untimed  systems  such  as  temporal  logics,  assertiond  meth¬ 
ods.  net» based  modds.  automata  theory  and  process  algebras.  While  most  formal  models  for 
n^time  systeoM  capture  delajrs  due  to  process  synchronizatioo.  they  abstract  out  resource- 
^peeffic  details  by  assuming  idealistic  operating  environments.  On  the  other  hand,  scheduling 
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algcvitlmu  and  analyzers  (25,  43,  34,  40,  41,  4,  38,  13, 42, 12,  35]  developed  for  real-time  sys¬ 
tems  capture  contention  on  shared  resources.  In  these  approaches,  however,  the  underlying 
cmnputatkm  model  is  graeralty  limited  to  simple  precedence  relations  between  process^. 
Since  complex  interactions  between  processes  are  not  captured,  these  approaches  cannot  be 
used  to  prove  properties  other  than  schedulability. 

To  bridge  the  gap  between  these  two  disciplines,  we  have  developed  a  formal  framework, 
called  ACSR  (Algebra  of  Communicating  Shared  Resources)  [11,  23).  ACSR  is  based  on  a 
computatkm  model  that  supports  the  notions  of  resources  and  priorities.  These  notions  are 
necessary  since  the  timed  behavior  of  the  system  is  affected  not  only  by  the  time  that  actions 
take  to  execute  but  by  delays  introduced  due  to  the  scheduling  of  actions  that  compete  to 
use  the  same  resource.  ACSR  allows  the  specification  of  resource  requirements  and  the 
verification  o(  timing  properties  to  take  the  availability  and  scheduling  of  resources. 

One  goal  of  this  fm>ject  was  to  develop  a  scalable  graphical  formalism  that  can  be  used 
to  specify  large  rM^time  systems.  For  this,  sw  developed  an  graphical  formal  specification 
language  fw  real-time  systems,  called  GCSR  (Graphical  Communicating  Shared  Resources). 
GCSR  is  a  formalism  developed  by  combining  two  real-time  methods.  Modechart  and  ACSR. 
GCSR  it  based  on  ACSR;  that  is.  there  is  a  well-defined  mapping  between  GCSR  and  ACSR. 
This  correspondence  is  very  important  since  this  implies  that  the  semantics  of  GCSR  is  well- 
ddined  became  the  theory  of  ACSR  has  been  oxnpieteiy  worked  out. 

GCSR  is  aiiiular  to  Modechart  in  a  sense  that  it  is  a  graphical  specification  language  and 
it  adopts  basic  graphical  ideas  such  as  node,  directed  edge  and  time  of  Modechart.  GCSR. 
however,  is  different  fiom  Modechart  because  GCSR  supports  the  notions  of  resource  and 
imority.  In  additioo,  GCSR  is  action  based  and  has  constructs  to  build  the  modular  and 
hierarchical  spedficatioo  of  a  real-time  system.  Because  of  the  resource-based  characteristics 
of  ACSR,  GCSR  also  supports  the  integrated  specification  of  functional  as  well  as  resource 
aspects  of  a  reid-time  system.  In  additkm  to  modularity,  this  integrated  specification  capa¬ 
bility  also  dhrtittgtttshes  GCSR  from  Modechart. 

There  ate  several  advantages  to  our  (orm^  method  GCSR: 

•  Scalak^ty;  For  formal  spcdficaikKu  to  be  practically  useful,  spedfications  must  be 
scalabie.  GCSR  b  designed  to  support  scalable  spedficalkKi:  in  particular,  GCSR  sup¬ 
ports  hierarchical  structures  through  nesting,  top-down  and  bottora-up  development 
of  ^Mcificatkma  through  naming  and  refinement,  and  modularity  through  limiting  vis¬ 
ibility  of  events. 
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•  Graphical  and  Textual  Specification  Languages:  It  is  easy  to  present  and  understand 
large  scale  systems  at  high-level  using  a  graphical  form.  However,  it  sometimes  is 
natural  and  faster  to  specify  the  detaib  of  a  large  system  textually.  In  our  toolkit 
environment,  a  real-time  system  can  be  specified  through  the  mixed  use  of  GCSR  and 
ACSR,  depending  on  whichever  medium  is  more  convenient..  Since  there  is  a  natural 
mapping  between  GCSR  and  ACSR  (and  vice  versa),  the  mixed  form  of  specifications 
does  not  result  any  ambiguity. 

•  Equivalence:  The  equivalence  relation  of  ACSR  indicates  when  two  systems  behave  the 
same.  Furthermore,  equivaknt  processes  can  be  substituted  one  another  inside  other 
procMs.  This  makes  it  possible  for  nuxlular  specification  and  analysis  of  large  systems. 
In  additkm,  process  may  be  minimixed  with  respect  to  the  equivalence  relation  before 
analysed,  which  often  times  simplifies  verification.  These  techniques  are  obviously 
applicable  to  GCSR  since  there  is  a  natural  mapping  between  GCSR  and  ACSR.  For 
example,  one  can  check  whether  or  not  two  GCSR  specifications  are  buimular.  This 
is  remarkable  since  other  graphical  specification  languages  usually  do  support  such  an 
equivalence  relattoo.  When  two  specificatioos  are  equivalent,  one  specification  inside  a 
large  system  specification  can  be  substituted  by  the  other  one.  We  note  that  we  have 
identified  many  useful  equivalence  relatioos  as  part  of  the  project  (see  Section  5.2). 

•  Resources:  Since  real-time  systems  omsist  of  several  shared  resources  such  as  cpu. 
memory  and  sensors,  it  is  natural  to  model  these  resources  in  terms  of  the  primitive 
notion  of  resource  in  GCSR.  Furthermore,  GCSR  can  be  used  to  consider  resource- 
induMd  constraints  daring  the  design  stage  of  the  development  cycle  and  to  eliminate 
untmplementable  design  alternatives  without  expensive  prototyping. 

e  Priority;  The  notion  of  priorities  is  always  present  in  real-time  systems  to  arbitrate  re¬ 
source  cootentiott.  Hence,  every  formal  method  devefoped  for  real-time  systems  should 
rapport  the  notion  of  priority;  otherwise,  it  may  not  possible  modd  system’s  behav¬ 
iors  cmrrectly.  It  soraetioEies  is  possible  to  encode  the  ootioD  d  priority  using  boolean 
formulas.  Hus,  however,  can  result  in  a  spedficalkm  which  it  difficult  to  understand 
dtw  to  expkracm  on  the  number  of  Boolean  conditions.  For  instance.  Modecbart  model 
of  the  HARM  misnle  systmn  is  quite  complicate  due  to  priority  encoding  {8}.  whereas 
the  OCSR  model  of  the  same  missile  system  is  simple  and  clear.  These  examples  are 
p wonted  in  later  sectkms. 
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•  PdMrmai  Sem&atics:  As  stated  earlier,  the  semantics  of  GCSR  is  defined  using  ACSR,  a 
real-time  process  algebra.  The  formal  semantics  determines  the  behaviors  of  a  GCSR 
specilicatioa  precisely  and  unambiguously.  This  in  turn  makes  it  possible  to  prove  the 
properties  of  a  GCSR  specihcation  rigorously  and  mathematically. 

•  Executable:  Since  ACSR  has  well-dehned  operational  semantics,  a  GCSR  specification 
is  executable.  There  are  a  few  advantages  for  executable  specification.  One  is  that 
it  can  be  used  as  a  fast  prototype.  Another  is  that  may  help  to  detect  unintended 
behaviors  of  the  specification,  before  attempting  to  prove  its  correctness. 

•  Sjmchroflous  and  Asynchronous  Communicatkm:  GCSR  support  both  synchronous 
and  asynchronous  communicatioos.  Asynchronous  broadcasting  events  are  essential  to 
describe  events  from  the  environment.  Furthermore,  we  have  experienced  in  many  oc- 
caakms  the  needs  for  broadcasting  events  during  the  specification  of  real-time  systems. 

•  Dense  ami  Discrete  Time:  Although  GCSR  is  based  on  discrete  time,  it  can  easily  be 
extended  to  dense  time  GCSR  since  we  have  already  completed  the  developmeat  of 
dense  time  ACSR  (fij. 

The  toolkit  environment  we  designed  consists  of  a  mrau-driven  graphical  user  interface, 
a  graphics  editor,  analysis  toob  and  the  interfaces  between  the  components. 

The  graphical  tt$er  interface  provides  a  set  commands  for  managing  specifications, 
activating  tli«  graphics  editor,  performing  formal  analysis  of  a  specification  and  terminating 
the  environinent. 

A  specificatioo  is  represented  in  terms  of  graphs  to  the  environment  A  user  creates, 
views  and  modifica  a  spedficatiwi  using  the  graphics  editor  which  u  based  on  icons  and 
memis.  The  editor  provides  the  following  operations  on  graphical  objects:  copy,  delete. 
p«^,  ahgu.  enlarge,  shrink,  etc.  A  large-KaJe  system  u  represented  by  a  set  erf  graphs  and 
their  hierarchy.  The  editor  provides  toots  of  scrolling  the  graph  window  and  navigating  ine 
hierarchy  of  the  graphs. 

A  spccificatioa  can  be  converted  automatically  to  a  state  machine  for  analysis.  Once  a 
spectftcalion  has  been  OMverted  to  a  state  machine,  the  analyst  may  execute  tbe  specifica¬ 
tion  and  test  it  to  determine  its  reasonableness.  Tbe  analv^st  may  then  apply  optional  state 
aminiiaatjoa  algorithms  to  the  specificatioo.  Though  tbe  dfectiveoe»i  of  state  minimiza¬ 
tion  win  vary,  socceseful  applkatioo  of  this  process  can  significantly  reduce  tbe  computing 
fawwtfcet  required  by  later  analysis  phases. 


Th«  anaiysis  of  the  state  machine  will  be  carried  out  using  the  following  analysis  tools; 
The  first  analysis  tool  is  a  simulation  tool  that  demonstrates  operational  behaviors  of  a 
specification  by  executing  the  stale  machine.  The  second  analysis  tool  is  a  model  checking 
todi  that  will  allow  the  specification  to  be  t^ted  against  real-time  logic  propositions.  The 
third  analysis  tool  is  a  state  exploration  tool  that  can  be  used  to  generate  valid  traces  of 
actions  for  the  specification  being  analyzed.  The  fourth  analysis  tool  will  test  for  equivalence 
between  two  or  more  alternative  specifications. 

The  nwt  of  this  report  is  organized  as  follows:  In  Section  2,  we  describe  briefly  .ACSR 
and  Modechart.  The  description  of  ACSR  includes  a  set  of  extensions  that  we  made  to 
ACSR  for  this  project.  We  also  compare  their  semantics  and  motivate  why  we  developed 
a  new  graphical  language  GCSR  instead  of  using  Vlodechart  Section  2.3  contrasts  their 
expreaaivencta  using  the  HARM  missile  system  example.  Section  3  details  the  syntax  and 
semantics  of  GCSR.  We  explain  how  to  transUae  from  ACSR  to  GCSR  and  vice  versa.  In  ad¬ 
dition,  we  describe  a  set  of  graph  reductions  that  are  developed  to  enhance  the  readability  of 
GCSR  specifications.  Section  4  provides  example  GCSR  spccificatioas  few  telephone  system, 
mouse  system,  railroad  crossing,  sensor  system,  and  router  systems.  SeciKtn  5  summarizes 
our  ittvestigation  on  automatic  analysis  techniques.  Section  5  1  briefly  explains  the  state 
minimiaation  algorithm  s>e  plan  to  implement.  Section  5.2  identifies  a  set  of  equivalence 
reiatkMis  that  are  sseaker  than  the  <mes  we  currently  have  Section  5  3  desenbe*  logic  that 
we  have  designed  to  (acilitaie  the  partial  specification  (t  e  .  requirement  specificaiioal  and 
model  checking  of  GCSR.  Sectioo  6  describes  the  overall  structure  of  the  toolkit  environ¬ 
ment  that  sse  proposed  to  implement  dunng  Phaae  U  of  this  project  and  identifies  existing 
so^ware  cocnp<menis  that  can  be  reused /adapted  (or  the  implement  at  kmi 


g 


2  Background 

Tike  proposed  tool*  axe  baaed  on  our  real-time  algebra  called  ACSR  (Algebra  of  Commu- 
ntcating  Shared  Reacmrces).  Section  2.1  brirfy  overviews  ACSR.  During  Phase  I.  we  have 
investigated  a  possibility  <rf  using  Modechart  as  a  graphical  language  for  ACSR.  In  Section 
2.2,  we  briefly  explain  Modechart.  Section  2.3  contrasts  the  semantic  differences  between 
ACSR  and  Modechart.  As  shown  in  2.3,  it  is  possible  to  translate  Modechart  to  ACSR. 
However,  because  ACSR  has  more  features,  it  is  not  possible  to  capture  all  aspects  of  ACSR 
without  extending  Motkchart.  Our  attempt  to  extend  .Modechart  has  resulted  in  a  new 
graphical  language,  which  is  described  in  Section  3.  .As  an  illustration  of  the  expressive¬ 
ness  of  ACSR,  we  specify  the  HARM  Missile  example  in  ACSR  and  compare  it  with  the 
Modechart  speciflcatkxi  2.3. 

3.1  ACSR:  Algebra  of  Commiaucating  Shared  Resources 

This  section  describes  the  syntax  and  operatwMul  tiemantics  of  .\CSR  (the  .\)gebra  of  Com¬ 
municating  Shared  Resources),  a  real-time  process  algebra  that  incorporates  the  notions 
of  cmsjDunkatioQ.  concunency,  resources,  and  pnonties  into  a  single  formalism.  ,\CSR  is 
completely  described  in  (33| 

Actions.  When  mocMing  a  process  with  algebrsK  expremons.  the  progress  of  the  pro- 
ccw  through  Its  ioleractKMM  snih  external  ageou  is  modeled  by  tbe  executuxi  cd  discrete 
'^actions.*  ACSR  uses  two  d^inct  action  types  to  model  computatioa  time  and  resource 
consuming  actions,  and  instantaneous  evenis. 

Timed  .4clM«a-“We  consider  a  system  to  be  composed  of  a  finite  set  of  senaily  reusable 
resourtsu,  denoted  by  R.  An  action  that  coosuities  one  '^ich*  of  time  is  drawn  from  the 
domaitt  RR  x  M)  (the  power  set  trf  R  x  fi\,  with  the  restriction  that  each  resource  be 
reprenented  at  most  once.  .As  an  example,  tbe  stnglrton  action.  f(e.pt}.  denotes  the  tue  of 
some  resource  r  €  R  running  at  pnonty  level  p  Pnonty  values  range  oxer  H.  with  0  being 
the  hiweet  (hNwt  preemng)  pnonty.  and  pnonty  increasing  with  mcreaaing  p  The  action  • 
repreeents  idHag  (be  one  time  unit,  since  all  resources  are  inactive 

We  uM  Pn  to  denote  the  domain  of  tuned  actions,  and  we  let  A.  B.C  range  oxer  Pn 
We  defbe  p(A)  to  be  the  set  of  resources  used  by  tbe  actum  A.  e  g  p( {(*■,. p,).(r3.pj)| )  = 
{^1.  We  also  use  e.|  A)  to  denote  the  prxmty  level  of  the  action  A  in  the  tewoiirce  r.  e  g 

*  Pi  By  convention,  if  *■  riot  in  MAt.  then  r-(A)  ==  0 


In^antaneous  Events — We  call  iniitantaneous  actions  events,  which  provide  the  basic 
83naciiroiiizatioa  in  our  process  algebra.  An  event  is  denoted  by  a  pair  {a.p).  where  a  is  the 
UAel  ai  the  event,  and  p  is  its  pnority.  Again,  priority  values  range  over  N  with  0  being 
the  least  pressing  priority.  Labels  are  drawn  from  the  set  L  U  E  U  {t}.  where  if  a  is  a  given 
label,  we  say  that  d  is  its  inverse  label,  i.e.  a  —  a.  A  label  and  its  inverse  can  be  thought 
as  naming  complementary  ends  of  a  communication  channel.  .As  in  CCS[31j,  the  special 
identity  label,  t,  arises  when  two  events  with  inverse  labels  are  executed  in  parallel. 

We  use  Ve  to  denote  the  domain  of  events,  and  let  e,  /  and  g  range  over  T>e.  We  use 
1(e)  and  »(e}  to  represent  the  label  and  priority,  respectively,  of  the  event  e. 

Finally,  the  entire  domain  of  actions  is  P  =  “Dr  U  P^,  and  we  let  a  and  ^  range  over  P. 

ACSR  Syntax  and  Semantics,  Let  P,  Ft,  Pj,  and  Pj  range  over  the  domain  of  terms, 
and  let  X  range  over  the  domain  of  term  variables.  Additionally,  we  assume  an  infinite  set 
of  free  term  variables.  FV  ACSR’s  syntax  is  pven  by  the  grammar  of  Figure  1. 

P  NlLl.AiPie.PlP, +  P,  lAilP,  i 

P  1  (Pli  I  P\F  1  rec  X.P  I  .V 

Figure  I :  Syntax  of  .ACSR  Process  Expressions 

NIL  is  a  process  that  executes  no  actioQ  (i.e.,  it  is  initially  deadlocked).  There  are  two 
preftx  operators,  corresponding  to  the  two  types  of  actions.  The  first.  :  P.  executes  a 
timed,  resource-coosunung  action  A,  consumes  one  time  unit,  and  proceeds  to  the  process 
P  The  seccmd  prefrx  operator.  «.P.  executes  the  instantaneous  event  c.  and  proceeds  to  P. 
The  Choice  oficrator  Pt  +•  Pj  represents  noodeterminism  -  either  of  the  processes  may  be 
choeen  to  execute,  subject  to  the  event  offerings  and  resource  limitations  of  the  environment. 
The  operator  P|{|Pi  is  the  concurrent  exccutioa  of  P|  and  Pj. 

The  Scope  construct  P  A*  i  Pj.  Pi)  binds  the  process  P  by  a  temporal  5cope(24j.  and 
incoepoeates  both  the  features  of  timeouts  and  interrupts.  We  call  t  the  lime  bound,  where 
f  €  Jlf*U{oo)  (i.e..  f  is  either  a  noa  oegati%'e  integer  or  infinity)  P  executes  for  a  maximum 
ot  t  time  units.  The  scope  may  be  exited  in  a  number  of  w^v-s  First,  if  P  successfully 
tennittates  within  time  I  by  executing  an  event  labeled  with  a.  then  control  proceeds  to  the 
^•occcse-haadler''  P\  {here,  a  may  be  any  label  other  than  r Second,  if  P  fails  to  terminate 
within  time  I.  then  control  proceeds  to  the  timeout  except  ion -handler*  Pj  Lastly,  at  any 


time  while  P  is  executing  it  may  be  interrupted  by  Ps’s  execution  of  a  timed  action  or 
instzmtaneous  event,  and  the  scope  is  then  departed. 

The  Close  operator,  [P]/,  produces  a  process  P  that  monopolizes  the  resources  in  /  C 

The  Restriction  operator,  P\P,  limits  the  behavior  of  P:  events  with  labels  in  F  are 
permitted  to  execute  only  if  they  synchronize  and  become  the  internal  event  t.  The  process 
rec  X.P  denotes  standard  recursion,  2dlowing  the  specification  of  infinite  behaviors.  The 
term  X,  without  a  “rcc”  binding,  is  a  free  variable  that  belongs  to  the  infinite  set  FV. 

The  semantics  of  ACSR  is  defined  in  two  steps  [23]:  unprioritized  semantics  that  provides 
all  behaviors  ignoring  priority  information  and  then  prioritized  semantics  that  eliminates  un¬ 
prioritized  behaviors  through  priority  arbitration.  Here,  we  only  describe  the  unprioritized 
semantics  of  ACSR  by  developing  the  unconstrained  transition  system.  A  transition  is  de- 

Or 

noted  as  P  - ►  P*,  for  P  and  P'  processes  and  a  an  action.  Within  no  priority 

arbitration  is  made  between  actions. 

The  two  rules  for  the  prefix  operators  are  axioms,  i.e.  they  have  premises  of  true.  There 
is  one  rule  for  time-consuming  actions,  and  one  for  events. 


ActT 


A:P 


ActI 


e.P  P 


For  example,  the  process  {(rj.pi), (rj.pj)}  :  P  simultaneously  uses  resources  ri  and  r2  for 
one  time  unit,  and  then  proceeds  to  P.  Alternatively,  the  process  (a,  p).P  executes  the  event 
“(a.p),”  and  proceeds  to  P. 

The  rules  for  Choice  are  identic2d  for  both  timed  actions  and  instantaneous  events  (and 
hence  we  use  “o”  as  the  label). 


ChoiceL 


ChoiceR 


Q^Q' 


P  +  Q^P'  p  + 

As  an  example,  (a,7).P  -f  {(ri,3),  (rj,  7)}  :  Q  may  choose  between  executing  the  event 
(o.7)  or  the  time-consuming  action  {(ri,3),(rj,7)}.  The  former  behavior  is  deduced  from 
rule  ActI,  while  the  latter  is  deduced  from  ActT. 

The  Parallel  operator  provides  the  basic  constructor  for  concurrency  and  communication. 
The  first  rule,  ParT,  is  for  two  time-consuming  transitions. 


ParT 


p  P'^Q  Q' 
P||Q  '•iifi* 


(p(.4i)np(A2)  =  0) 


Note  that  timed  transitions  are  truly  synchronous,  in  that  the  resulting  process  advances 
only  if  both  of  the  constituents  take  a  step.  Thus,  care  must  be  taken  to  insure  that  every 
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step  of  a  timed  computation  offers  one  or  more  timed  alternatives,  lest  the  lack  of  a  timed 
step  should  “stop  the  clock.”  The  condition  p(>li)  n  p(i4j)  =  0  mandates  that  each  resource 
is  truly  sequential,  and  that  only  one  process  may  use  a  given  resource  during  any  time  step. 

The  next  three  laws  are  for  event  transitions.  As  opposed  to  timed  actions,  events  may 
occur  asynchronously  (as  in  CCS  and  related  interleaving  models). 


ParIL 


P 

P\\Q 


F 

nQ 


ParlR 


Q' 

P\\Q' 


ParCom 


pjlQ  F\\Q' 


The  first  two  rules  show  that  events  may  be  arbitrarily  interleaved.  The  last  rule  is  for  two 
synchronizing  processes,  i.e.  P  executes  an  event  with  the  label  a,  while  Q  executes  an  event 
with  the  inverse  label  a.  Note  that  when  two  events  synchronize,  their  resulting  priority  is 
the  sum  of  their  constituent  priorities. 

The  Scope  operator  possesses  a  total  of  five  transition  rules  describing  the  various  be¬ 
haviors  induced  by  a  temporal  scope.  The  first  two  rules  show  that  as  long  hs  t  >  0  and  P 
does  not  execute  an  event  labeled  with  h,  the  executions  of  P  continue. 


ScopeCT 


ScopeCI 


_ P  ^  F _ 

P  /^\  {Q,  R,  S)  -  U  F  A*_,  (Q.  H.  S) 

p  -l^F  _ 

P  A',  (g.  US) -^F  A*  {Q.  fl. 5) 


(<>0) 

(/(e)#6.t  >0) 


The  SeopeE  (for  “end")  shows  that  P  can  depart  the  temporal  scope  by  executing  an  event 
labeled  with  h.  Upon  exit,  the  label  h  is  converted  to  the  identity  label  r;  however,  the  same 
prkvity  is  retained. 


ScopcE 


P 


F 


P/^\{Q,R,S)'^Q 


(t>0) 


The  next  rule.  ScopeT  (for  “timeout"),  is  applied  whenever  the  scope  times  out.  i.e.  when 
t  s  0.  At  this  point,  control  proceeds  to  the  exception  handler  R. 

ScopeT  p^^  \q s)  F 
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Fijudly,  ScopcI  shows  that  the  process  S  may  interrupt  (and  kill)  P  while  the  scope  is  still 
active.  Note  that  the  interrupt  step  may  be  one  of  several  options  offered  simultaneously. 
Also  note  that  scopes  may  be  nested  arbitrarily  deeply.  When  nested  scopes  use  the  same 
action  to  trigger  an  interrupt,  the  interrupting  a^rtion  will  propagate  upward  after  each 
interruption.  This  follows  from  rule  Scopel,  which  specifies  that  the  interrupting  action  is 
preserved. 


Scopel 


U>0) 


PA\iQ,R,S)^S> 

The  Restriction  operator  defines  a  subset  of  mstantaneous  events  that  are  excluded  from 
the  behavior  of  the  system.  This  is  done  by  establishing  a  set  of  labels.  F  (r  ^  F),  and 
deriving  only  those  behaviors  that  do  not  involve  events  with  those  labels.  Note  that  while 
P\F  restricts  P  from  communicating  with  other  processes  using  labels  in  F,  concurrent  sub¬ 
processes  sfithin  P  are  fttt  to  interact  with  one  another  using  these  labels.  Thus,  restriction 
can  be  viewed  as  the  assignment  of  dedicated  channels  for  communication  within  a  process. 
Note  also  that  time-consuming  actions  are  unaffected  by  restriction. 


R«sT 


Reel 


P\F  *1:2  p'\F 


(n.a  ^  F) 


While  Restriction  assigns  dedicated  channels  to  processes,  the  Close  operator  assigns 
dedicated  resources.  When  a  procen  P  is  onbedded  in  a  closed  context  such  as  [P]/,  we 
ensure  that  there  is  no  further  sharing  of  the  resources  in  /.  Assume  that  P  executes  a  time- 
consunting  action  A.  If  A  utilizes  less  than  the  full  resource  set  /.  the  action  is  augmented 
with  (r.O)  pairs  for  each  unused  resource  r  €  I  -  p{  A).  The  way  to  interpret  Close  is  as 
follows.  A  process  may  idle  in  one  of  two  ways:  it  may  either  release  its  resources  during 
the  idle  lime  ( represented  by  •),  or  it  may  hold  them.  Close  ensures  that  the  resources  are 
held.  (Instantaneous  events  are  not  affected.) 


Wi 


The  operator  rec  X.P  denotes  guarded  recursion,  allowing  the  specification  of  infinite 
behaviors. 


Rec 


pr  ^  ^/xi  —  F 

rec  X.P  —  F 
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p|»«e  is  the  siandvd  notation  for  substitution  of  rtc  X.P  for  eax:h  free  occurrence  of 

X  in  P.  By  guarded  recursion,  we  mean  that  all  occurrences  of  X  in  rcc  X.P  are  preceded 
by  8<xne  action  a.  For  example,  rec  .Y.(j4  :  X)  is  guarded,  while  rec  X.(X  +  A  :  X)  is  not. 

As  an  example,  considn  rec  X.{A  :  X),  which  executes  the  resource-consuming  action 
“A"  forever.  By  ActT,  A  :  {rec  X.{A  :  X))  — rec  X.{A  ;  X),  so  by  Rec,  rec  X.(A  : 
X)  — i-»rec  X.iA  :  X). 


Extenssons  to  ACSR.  To  make  ACSR  practical,  we  made  two  extensions.  One  extension 
is  to  include  the  notion  of  broadcasting.  In  ACSR,  we  introduce  two  symbols,  ??  and  !!  for 
broadcasting:  a??  denotes  receiving  an  event  through  the  broadcasting  channel  a,  and  a!! 
sending  an  event.  The  operational  semantics  for  a??  and  a!!  are  as  follows: 

^  — O' 

/>iiQ  -a  p'lio  Pile  no" 

_ _  Q  O'  p  ^  F 

o??.p  -1*  a??.P  Q\\P  ^  Ct\\P 

The  above  operational  semantics  are  basic  concepts  of  broadcasting  communication  which 
are  based  on  the  following  two  facts: 

•  Receiver  waits  indefinitely  until  sender  sends  a  message. 

•  Sender  proceeds  to  next  precess  immediately  after  sending  a  message  without  checking 
the  existence  of  receivers. 

In  ort^  to  model  broadcasting  communication  using  ACSR.  all  should  not  be  restricted, 
but  a??  must  be  always  restricted. 

Another  extension  is  to  augment  ACSR  with  operations  that  allow  the  use  of  ACSR  as 
a  more  practical  specificatioo  language.  These  operations  include:  a  process  name  bind¬ 
ing  operation  {P  »  Q),  generalized  parallel  and  choice  operations,  indexed  processes  (P[t] 
for  i  from  1  to  n),  event  {(p,e{«|))  and  resource  ({{p. r'(t))})  specifications.  The  detailed 
specification  of  these  additions  can  be  found  in  [7]. 


2.2  Modechart 

Modechart  is  a  graphical  specification  language  developed  to  provide  a  compact  and  struc¬ 
tured  way  to  represent  real-time  systems.  Modechart  is  a  variant  of  the  Statechart  language. 


The  motivation  of  Modechart  is  given  as  follows  [15]:  (1)  Statechart  is  too  liberal  in  per¬ 
mitting  the  forms  of  predicates  to  appear  in  the  conditions  for  enabling  state  transitions. 
As  a  resiilt,  it  is  difficult  to  prevent  anomalies  in  defining  a  semantics  for  Statechart.  (2) 
Statechart  does  not  provide  an  adequate  treatment  of  stringent  timing  constraints. 


MO 


Serial 

Ml 

Transioon  Cooditioa 

M2 

Action  A 

Action  A  :  descripdoa  of  A 

Figure  2:  An  example  of  modechart 


We  briefly  review  the  notions  of  mode,  transition  and  action  in  Modechart. 

Mode.  Modes  partition  the  state  space  of  a  system.  They  can  be  viewed  as  the  specification 
of  control  information  that  impose  structure  on  the  operation  of  a  system. 

Modes  can  be  nested  within  a  mode.  Nested  modes  are  related  either  serially  or  in 
parallel. 

StrioJ  modes — Serial  modes  specify  a  sequential  relationship  between  modes.  The  system 
operates  in  at  most  one  serial  mode  at  a  time. 

Parallel  modes — Parallel  modes  define  a  parallel  relationship  between  modes.  The  system 
operates  in  all  of  the  parallel  modes  simultaneously.  There  are  following  restrictions  on 
parallel  modes. 

•  A  transition  between  parallel  modes  is  not  allowed. 

a  A  transition  out  of  one  mode  requires  exit  out  of  all  other  modes  that  are  parallel  to 
it. 

Well-formed  modes — In  order  to  prevent  ambiguous  modechart  specifications,  the  notion 
of  well-formedness  and  the  UDIM  (Unambiguous  Designation  of  Initial  Modes)  condition  are 
developed.  The  semantics  of  modechart  is  only  valid  among  modecharts  of  which  modes  are 
well-fcwmed  and  satisfy  the  UDIM  condition.  Without  the  UDIM  idition,  a  well-formed 
mode  can  still  be  ambiguous  if  initial  modes  are  unspecified. 
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'IVansition  IVaiisitioD  between  two  modes  represents  a  change  in  the  control  flow  of  the 
system.  A  transition  is  an  instantaneous  event  which  takes  zero  time  unit.  Each  transition 
is  associated  with  a  condition.  The  condition  for  a  transition  is  of  the  form 

Cl  V  cj  V  •  •  •  V  c„ 

where  each  c,  is  either  a  triggering  condition  or  a  lower  and  upper  time  boui.  i^triction  on 
when  the  transition  may  be  taken. 

triggering  condition—  Triggering  condition  c,  is  of  the  form 

Pi  A-  -A-  -pn 

where  the  pi's  specify  a  condition  in  terms  of  the  occurrence  of  an  event  or  the  truth  values 
of  certain  predicates.  Each  pi  is  in  one  of  the  following  three  forms: 

1.  5  (or  .$)  is  true  at  time  t  if  the  the  state  variable  S  is  true  (or  false)  at  time  t.* 

2.  is  true  at  time  t  if  the  system  is  in  at  least  one  of  the  specified 
modes  at  a  finite  interval  up  to  time 

3.  E  is  the  occurrence  of  an  event  E  at  the  where  E  can  be  an 

•  external  event,  e.g.,  QE, 

•  event  denoting  start  of  an  action,  e.q.  t  A, 

•  event  denoting  completion  of  an  action,  e.g.,  i.4, 

•  event  setting  a  state  variable  to  true,  e.g.,  (5  :=  T), 

•  event  setting  a  state  variable  to  false,  e.g.,  (5  :=  F), 

•  event  denoting  entry  into  mode,  e.g.,  (3/1  :=  T),  or 

•  event  denoting  exit  from  mode,  e.g.,  {Ml  :=■  F). 

Lower/Upper  Bound  Condition — A  condition  Ci  denoting  a  lower/upper  bound  restriction 
is  of  the  form  (r,d),  where  r  is  a  non-negative  integer  denoting  a  delay  and  d  is  a  positive 
integer  or  oo  doaoting  a  deadline. 

There  are  three  special  forms  of  lower/upper  bound  condition:  alarm  r  =  (r,  r),  delay  r  = 
(r,oo),  and  deadline  d  —  (O.d). 

‘lo  HTL.  5(1.1)  (or  S{t,t))  is  true. 

’In  RTL,  for  some  Mi,  Mi{t,t)  is  true. 

*la  RTL.O(£,i)  =  ( is  true. 
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Actions.  The  basic  difference  between  actions  zind  mode  transitions  is  that  actions  take 
nonzero  time,  whereas  mode  transitions  take  zero  time.  In  Modechart,  each  action  in  a 
system  must  be  associated  with  a  mode.  Furthermore,  at  most  one  action  may  be  associated 
with  a  mode.  Thus,  if  two  or  more  actions  need  to  be  performed  when  a  system  is  in  a 
certain  mode,  then  the  designer  should  creat  a  child  mode  for  each  action. 

When  a  system  designer  wishes  to  specify  that  an  action  has  to  be  performed  when  an 
event  occtirs,  the  action  has  to  be  specified  in  the  destination  mode  of  the  transition.  This  is 
justified  since  a  transition  is  instantaneous  in  Modechart,  the  action  will  be  performed  upon 
<mtering  the  destination  mode. 

The  value  of  a  state  variable  is  changed  explicitly  after  completing  the  execution  of  an 
acti<m  which  takes  non-zero  units  of  time  to  perform.  Therefore,  the  value  of  a  state  variable 
is  changed  at  the  end  of  action  execution. 

2.3  Semantic  Difference  and  Translation 

In  this  section,  we  identify  semantic  differences  between  ACSR  and  Modechart. 

a  N on-delayed  event  os.  delayed  event— In  Modechart,  control  can  stay  inside  a  mode 
waiting  for  the  triggering  condition  to  be  true.  That  is,  suppose  we  have  a  serial  mode 
such  that  M  N.  The  ent'^ing  time  of  control  into  the  mode  M  may  differ  from 
that  into  the  mode  N.  On  the  other  hand,  in  ACSR,  process  cannot  wait  for  event, 
unless  waiting  possibility  is  explicitly  specified.  For  instance,  suppose  Q  is  an  ACSR 
process  such  that  Q  s  a.P.  Whenever  Q  is  executed  at  time  t,  the  event  a  must  occur 
at  time  t,  and  the  resulting  process  P  is  at  the  same  time  t.  The  delayed  event  in 
Modechart  can  be  emulated  by  a.P  +  0  '•  Q- 

•  Event  expression — In  ACSR,  events  can  not  be  composed  using  V  or  A,  that  is.  events 
are  atomic.  Modechart  can  have  an  event  expression  as  a  triggering  condition  of  a 
transition. 

s  Resource — ACSR  has  the  notion  of  resources.  The  use  of  resources  by  a  process  requires 
the  passage  of  time.  The  most  natural  Modechart  notion  to  ACSR  resource  is  the 
notion  of  action  which  is  defined  inside  a  mode.  Note  that  MCTool  does  not  support 
actions. 

a  Priority — The  choice  operator  in  ACSR  is  based  on  priority;  a  higher  priority  pro¬ 
cess  is  chosen.  When  priority  comparison  is  not  possible,  the  choice  is  done  non- 


detenninisticaily.  On  the  other  hand,  Modechart  does  not  support  the  notion  of  pri- 
<aity.  Wh«i  several  transitions  are  possible,  one  is  chosen  nondeterministically. 

•  Broadcasting  os.  synchronization — The  communication  mechanism  of  ACSR  is  syn¬ 
chronous  communication,  whereas  that  of  Modechart  is  broadcasting.  The  followings 
are  basic  concepts  of  broadcasting  communication. 

-  Receiver  process  (a??.P)  waits  until  a  sender  sends  a  message. 

-  Sender  process  proceeds  to  the  next  precess  iimnediately  after  sending  a 

message  without  checking  the  existence  of  receivers.  The  same  message  is  deliv¬ 
ered  to  all  waiting  processes. 

These  communication  behaviors  can  be  emulated  by  ACSR  as  follows: 

-  aV..P  by  recX(a?.P -I-  0  :  X) 

-  aW.Q  by  rccX.{al.X  +  Q) 

•  Mode  variable  and  value  test—  Whenever  control  enters  and  exits  a  mode  M,  Mod¬ 
echart  automatically  generate  events,  ->  M  and  A/->.  respectively.  Also,  there  is 
a  condition  for  each  mode  M  such  that  M  =:=  true  or  M  =:=  false  depending  on 
whether  control  is  in  the  mode  M  at  the  current  time  and  is  not  in  M,  respectively.  A 
mode  variable  is  encoded  using  ACSR  as  follows:  Suppose  Af  is  a  mode. 

M  ^  MF 

MF  ^  falseM\.MF  +  enterM?.MT  +  9  :  MF 

MT  ^  trueMlMT  +  exit^?.MF  +  9  :  MT 

M  signals  false^l  to  whichever  process  needs  it  until  M  is  entered.  After  M  is 
entered,  it  signals  true  JVf  until  it  is  exited. 

•  State  variable — ^Similar  to  mode  variables,  Modechart  also  supports  state  variables.  For 
instance,  action  {Set  Var  :=  F)  and  boolean  condition  {Var  —=  true).  The  behavior 
of  a  state  variable  can  be  encoded  as  follows:  We  assume  that  the  initial  value  of  the 
variable  Var  is  false. 

Var  ^  VarF 

VarF  false.Varl.VarF  +  set.VarH.VarT  +  %  :VarF 

VarT  ^  true.Varl.VorT  +  set.VarF7.VarF  -i-  0  :  VarT 
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•  Timeout — ACSR  has  a  powerful  timeout  which  is  whenever  timeout  occurs  the  timeout 
process  must  be  executed.  A  similar  notion  of  timeout  in  Modechart  is  alarm  t.  which  is 
[f,  t}.  However  there  are  two  differences.  1)  A  mode  can  have  several  alarm  transitions. 
For  instance,  a  mode  can  have  two  transitions  where  for  each  triggering  condition  is 
alarm  5  and  alarm  6,  respectively.  2)  A  mode  may  have  two  transitions;  one  with 
alarm  5  and  another  with  a  condition  c.  Here,  if  the  condition  c  is  true  at  time  5, 
either  transition  can  be  executed  nondeterministically. 

IVannlation  from  Modechsurt  to  ACSR.  It  seems  that  the  subset  of  Modechart  which 
is  supported  by  MCTool  can  be  translated  easily  into  ACSR.  Such  a  subset  of  MCTool  has 
the  semantics  of  ACSR,  hence,  no  ambiguity  is  possible.  In  this  case,  a  real-time  system  can 
be  specified  using  MCTocd  and  the  correctness  of  the  system  can  be  verified  using  ACSR 
based  analysis  toob. 

Tlwre  is  one  major  problem  with  this  approach  because  ACSR  is  based  on  synchronous 
communication,  whereas  Modechart  is  based  on  broadcasting.  There  are  two  ways  to  han¬ 
dle  broadcasting  mechanism:  one  way  is  to  extend  ACSR  so  that  the  new  ACSR  includes 
broadcasting  events,  and  the  other  way  is  to  emulate  broadcasting  mechanism  using  ACSR 
synchronous  communication  as  seen  in  the  previous  section. 

We  now  describe  how  a  subset  Modechart  may  be  translated  into  ACSR.  We  assume 
that  the  modecharts  used  here  are  well-formed. 

1.  Mode  names:  we  define  ACSR  variid>les  associated  with  the  names  of  modes.  Let 
Pf  Pi,  Q  and  Qi  be  such  mode  variables. 

2.  Primitive  mode:  A  primitive  mode  can  be  encoded  as  rec  .Y.9  :  X  in  ACSR. 

3.  Parallel  mode:  Suppose  P  is  a  parallel  mode  with  submodes,  P] . Pn  and  no 

out-gmng  transition.  The  ACSR  translation  for  P  is  the  following 

pV P,li  IIP. 

4.  TVansition:  Now  we  translate  mode  transition  such  that 

7* ;  p  .22*  (J. 

First,  we  translate  triggering  condition.  We  have  following  three  cases  according  to 
the  type  of  enabling  condition. 
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•  Event  denoting  entry  into  mode,  ->  .V: 

T  ^  entry Ml.recX. (exit  J>\.X  +  Q) 

•  Event  denoting  exit  from  mode,  M—>: 

T  ^  exitJ4’i.recX.{exitJ>\.X  +  Q) 

•  Event  denoting  status  of  mode,  {M  ==  true)  or  {Af  ==  false): 

T  ^  true J^?.recX. (exit  J^l.X  +  Q) 
or 

T  ^  /alseJif?.reeX.(exitJ>iX  +  Q). 

5.  SerUJ  mode:  Now  we  describe  how  to  translate  a  mode  M  along  with  translations 
7i,  T), . . . ,  Tn,  Tout  which  come  from  the  mode  M. 

We  assume  that  the  mode  \f  is  the  ACSR  process.  Also,  we  assume  that  T,  is  the 
ACSR  process  associated  with  the  transition  T.  and  Tout  is  the  transition  with  timing 
constraint  [/,  u]. 

M  ^ 

Tx  ^  ••• 

Tout  ^  ••• 

MT  ^  M  C^i(Tout,Tx  +  Tj+  -  Tn) 

+  A/ A/+I  (Tout,  T"!  +  Ti  +  — Tn) 

+  A/ A,  (Toot,  Ti  +  Ta  +  ■  •  ■  Tn) 

Whare  the  transition  with  timing  constraint.  Tout  is  defined  as 

Tout  ^  recX.{exitM\.X  +  Q) 

A  transition  with  the  alarm  t  is  translated  into  ACSR  as  follows: 

MT  ^  A/A,(Toot.r, +  r2+  -  Tn) 

Note  that  in  this  ACSR  transition,  after  passing  t  time  unites,  timeout  transition  (a 
transition  with  alarm  t  condition)  must  be  executed,  regardedless  of  other  transitions. 
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'nransiation  from  ACSR  to  Modechart.  Since  a  subset  of  ACSR  can  be  regarded  as 
a  restricted  form  of  Modechart  in  terms  of  structure,  translation  from  an  ACSR  term  to  a 
Modechart  specification  seems  straightforward  as  seen  in  Figure  3  except  for  synchronous 
cwnm unication,  priorities,  resources  and  resource  cloeure.  We  are  identifying  on  how  to 
esctend  Modechart  to  support  them.  This  study  is  to  determine  how  MCTooi  can  be  used 
as  a  graphical  fr<nit-«id  to  ACSR  based  tools. 


Figure  3:  An  example  of  translation  of  ACSR  to  Modechart 


Figure  3  illustrates  how  ACSR  terms  can  be  translated  into  Modechart.  It  is  clear 
that  two  prefix  operators,  and  should  be  translated  into  serial  modes,  since  the 
semantics  d  prefix  operators  are  identical  to  serial  modes.  Since  Modechart  semantics  allows 
control  to  stay  in  a  mode  until  a  tri|^ering  condition  is  satisfied,  the  semantics  of  modechart 
corretponding  the  prefix  a.P  is  slightly  different  from  that  of  ACSR.  This  is  because  the 
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event  o  should  occur  at  the  same  time  the  mode  P*  is  entered.  This  problem  can  be  solved 
by  adding  an  additional  time-out  transition  from  P*  so  that  whenever  the  transition  with 
the  event  a  is  not  immediately  chosen,  the  next  choice  is  an  error  state.  Similarly,  timeout 
t  in  ACSR  can  be  translated  into  serial  mode  with  timing  information  [t,  i]. 

The  above  identifies  a  subset  of  ACSR  which  can  be  translated  into  the  Modechart 
(defined  in  MCTool).  To  translate  from  the  full  feature  of  ACSR  to  Modechart,  the  following 
notions  should  be  supported;  prioritized  choice,  resource  closure  operator,  event  restriction 
operator,  scope  operator,  resources.  Section  3  describe  a  graphical  language  with  these 
operators. 

Modediart  Model  of  the  HARM  MiMtle  System.  Figure  4  is  the  modechart  model 
of  the  HARM  missile  system  developed  by  NRJL  (8].  The  above  modechart  illustrates  HARM 
missile  system  a>ntroi  flow  but  transitioD  conditions  are  hidden.  The  following  is  a  transition 
ccmditkm  from  mode  CPU  jdle  to  mode  MPSP^warded^u  of  the  missile  8ystem[8]. 

CPUl.idle**>MFSP.a«arded.cpa :(KTS. wax else  k  KTS-vork^^alse 
t  R.vsdtwwfalse  k  PL , «ork«»f alee  t  DLP.«ait«wfaIse  k  DLP.vork^false 
i  OT.«ait«wfalse  t  0T.«ork^alae  k  HF$P.vait»«trae  ft  ‘MFSP. suspend)  I 
(NTS. *alt"wf else  ft  KTS,«or]p»false  ft  PL.eait»«false  ft  PL . eork-^alse 
ft  INJ’.*ait<»false  ft  OLP . work^alse  ft  ITr.snapeiid  ft  MFSP. vait»»t rue 
ft  'MFSP. suspend)  I 

(NTS. sait«wf also  ft  NTS.sorii«^alse  ft  PL.salt*^alse  ft  PL.sork>»false 
ft  OLP. suspend  ft  UT.sait^wfalse  ft  OT.sorJt»^alse  ft  MFSP . sait»»true 
ft  I MFSP. suspend)  I 

(MTS. sal t*wf also  ft  MTS. sork««f also  ft  PL.sait>^aIse  ft  PL.work>*false 
ft  IH.P. suspend  ft  UT. suspend  ft  MFSP. sal tMtrue  ft  ! MFSP. suspend)  I 
(MTS.salt«"false  ft  MTS.sork«»false  ft  PL. suspend  ft  DLP.salt«false 
ft  DLP.sorlPMifalse  ft  UT.salt**^alse  ft  ITT. sork"wf else  ft  MFSP. salt«at rue 
ft  fMPSP. suspend)  I 

(NTS.salt«wfalse  ft  MTS.sork«4alse  ft  PL. suspend  ft  DLP.salt«»false 
ft  OLP.sorkMfais«  t  OT. suspend  ft  MFSP.salt«^rue  ft  ! MFSP. suspend)  I 
(MTS.saltw^alse  ft  MTS . sork*Mf alse  ft  PL. suspend  ft  DLP. suspend 
ft  t)T.salt>MrfnXae  ft  UT.sorkw^alse  ft  MFSP.salt««true  ft  ! MFSP. suspend)  i 
(MTS. salt*«f else  ft  MTS.sorkw^alse  ft  PL. suspend  ft  DLP. suspend 
ft  OT. suspend  ft  NFSP.saltMtme  ft  ? MFSP. suspend)  I 
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Figure  4:  Modechwt  specificattou  of  the  HARM  Missile  example 


(NTS . •iisp«Bd  ft  PL.irait*«fals«  ft  PL.«ork««faIstt  ft  DLP.«ait»«false 
ft  OLP . «orkw>f als«  ft  irT.«ait*«fal8«  ft  UT.frork*«false  ft  NFSP.irait««tnie 
ft  flffSP-aaspaad)  I 

(NTS.nspand  ft  PL.«ait*«fal8a  ft  PL.«ork««fal88  ft  DLP.«ait«*fal8« 

ft  INJP.«ork*ofal8a  ft  irT.8U8p«iid  ft  KFSP . iiait«*tru«  ft  'NFSP. 8U8p«nd)  I 

(MTS . sti8p«id  ft  PL.«alt»*fal88  ft  PL . «ork««f al88  ft  DLP.8U8p«nd 

ft  UT.«ait«^al8«  ft  UT . work«*f al88  ft  MFSP . wait^-tra*  ft  !MFSP.8U8peiid)  I 

(NTS.s«8p«ad  ft  PL.>ait«^al8«  ft  PL . 8ork««f al8a  ft  DLP.8U8p«nd 

ft  OT.fuspaiid  ft  NFSP.«ait«*tnM  ft  >KFSP.8a8p«nd)  I 

(NrS.8«8p«Dd  ft  PL.8U8p«ad  ft  DLP.«ait>«fal88  ft  DLP.vork*"fal88 

ft  OT.*ait«^als«  ft  OT.«ork^al8«  ft  NFSP.«ait«»tni8  ft  *NFSP.8a8paiid)  i 

(NTS.8«sp«iid  ft  PL.stiapaad  ft  OLP.«ait««fal8«  ft  DLP.«ork*^al88 

ft  UT.«tt8p«id  ft  MFSP.vait«aitni8  ft  !MFSP.8asp«ad)  I 

(KTS.8««p«Bd  ft  PL.8n8p«ad  ft  DLP.8xi8p«&d  ft  in‘.«axt>«fal8a 

ft  OT.vork^^alt*  ft  MFSP.vaxt«*tni«  ft  !MFSP.8a8p«ad)  I 

(NrS.8«8p«Bd  ft  PL.8«8p«ad  ft  OLP.8V8p«id  ft  OT.8n8p«ad  ft  MFSP.valt»«txru8 

ft  ^NFSP.8«sp«B4)  ; 

Hus  it  rather  complex  cmidtlioo,  which  is  resulted  from  trying  to  represent  prioritized 
■chedtiiing  without  the  notion  of  priority. 

ACSR  Modkl  of  the  MiaaUe  System.  The  following  is  ACSR  specification  for  the 
previous  modechart  example  of  HARM  missile  system.  Because  of  the  notion  of  priority,  the 
ACSR  specihctUioa  »  quite  simpler  than  that  of  Modechart. 
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HARM  [MTS\\PL\\DPL\\UT\\MFSP]  {CPU} 

MTS  ^  IDLE {mu  MTS. Work,  mh) 

MTS. Work  [CPU, 5}^  As  {mUMTS,{}  :  MTS. Work) 

PL  ='  IDLE  A-io{mUPL.Work,mL) 

PL.Work  {CPU,4}°°  AaimUPL,}}  :  PL.Work) 

DLP  ^  IDLE  A2i{mUDLP.Work,mL) 

DLP.Work  ^  {CPU,Z}^  AsimUDLP,{}  :  DLP.Work) 

UT  ^  IDLE  Ai!,{mUUT.Work,mL) 

UT.Work  {CPU,  2)^  As  {mUUT,  {}  :  UT.Work) 

MFSP  ^  IDLE  A,  (mu  MFSP.Work,  NIL) 

MFSP.Work  {CPU,  l}^  A»  (NIL,  MFSP,  {}  :  MFSP.Work) 
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3  GCSR;  Graphical  CSR 


In  this  section,  we  present  a  graphical  specification  language  (GCSR)  that  has  a  formal 
semantics  based  on  the  Algebra  of  Communicating  Shared  Resources  (ACSR).  GCSR  is 
action  based,  and  has  constructs  to  build  a  modular  (through  limiting  visibility  of  events)  and 
hierarchical  (through  node  nesting)  specification  of  a  real-time  system.  Its  semantics,  ACSR, 
is  a  formalism  that  supports  the  integrated  specification  of  functional  aspects  of  a  real-time 
system  and  its  nm-time  resource  requirements.  The  outline  of  this  section  is  as  follows. 
Section  3.1  introduces  the  syntax  of  GCSR  and  validity  criteria  of  GCSR  specifications. 
Section  3.3  describes  informally  the  semantics  of  GCSR,  then  gives  the  translations  between 
ACSR  and  GCSR.  Section  4  presents  several  examples. 

3.1  GCSR  Syntax 

We  now  describe  the  building  blocks  of  a  GCSR  graph,  and  how  they  are  used  to  construct 
a  GCSR  specification. 

Building  blocks.  The  basic  building  blocks  in  GCSR  are  nodes  that  can  be  connected 
with  directed  edges.  GCSR  has  three  types  of  nodes  (NIL,  Dot,  and  Box)  and  two  types  of 
directed  edges  (external  exit,  and  internal  exit.)  Figure  5  shows  the  graphical  symbols  of 
these  building  blocks. 

Nodes.  The  NIL  node  is  a  special  node  that  marks  the  end  of  a  sequential  execution.  The 
Dot  node  is  either  a  specification  point  (place  in  Petri  net  terminology)  where  an  event  must 
be  instantaneously  produced,  or  a  specification  point  where  the  selection  among  multiple 
computations  (work  to  do)  must  be  instantaneously  made.  The  necessity  of  the  special  NIL 
and  Dot  nodes  will  become  clearer  in  Section  3.3  where  we  present  the  semantics  of  GCSR. 
A  Box  node  represents  a  computation  component  that  may  consume  resources  and  time.  A 
Box  can  either  be  primitive,  i.e.  its  internal  structure  is  hidden,  or  complex,  i.e.  its  internal 
structure  is  visible.  A  complex  Box  can  contain  one  component  or  two  (or  more)  components 
that  are  executed  concurrently.  A  reference  Box  refers  to  another  GCSR  specification;  such 
a  node  allows  stepwise  and  compact  graphical  specifications. 

As  the  extended  BNF*  for  the  GCSR  structures  in  Figures  6  and  7  shows,  a  node  has 
a  name  that  uniquely  identifies  it:  a  primitive  box  has  a  possibly  empty  set  of  resources 

*We  followed  the  notatioa  of  programming  languages  as  used  in  [30.  19] 


NIL 


NIL  node 


Figure  5:  GCSR  types  of  nodes  (top)  and  edges  (bottom). 
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{Resource);  a  complex  box  has  in  addition  a  set  of  dedicated  resources  (Close),  a  set  of 
observable  events  (Ohserv),  a  set  of  local  synchronization  events  (Restrict),  and  a  list  of 
GCSR  components  representing  the  internal  structure  it  contains.  In  the  case  of  a  reference 
box,  these  attributes  are  deduced  from  the  GCSR  graph  that  defines  it. 

Eldges.  Nodes  can  be  linked  together  with  edges  that  do  not  cross  node  boundaries  to  form 
a  GCSR  Specification.  There  are  two  types  of  edges:  internal-exit  edges  to  reflect  the  end 
of  execution  from  inside  a  Box  node  and  to  transfer  control  to  another  node  at  a  higher 
level,  and  external-exit  edges  to  reflect  sequential  flow  of  control  zunong  nodes  at  the  same 
level.  The  two  types  of  edges  simplify  a  hierarchical  graphical  specification  and  make  the 
transition  semantics  unambiguous.  While  the  activation  of  an  internal-exit  edge  depends  on 
the  source  node,  that  of  an  external-exit  edge  depends  on  the  environment.  This  semantic 
distinction  between  the  two  types  of  edges  will  be  addressed  in  Section  3.3. 

An  internal-exit  edge  always  has  a  Box  source  node,  zind  is  labeled  with  an  event,  “exit 
event”  (which  corresponds  to  “exception”  in  ACSR).  An  external-exit  edge,  on  the  other 
hand,  can  be  either  unlabeled  or  labeled  with  an  event  or  time.  An  unlabeled  edge  and  an 
event  labeled  edge  can  have  either  a  Dot  or  a  Box  source  node,  while  an  edge  labeled  with 
time  always  has  a  Box  source  node.  Although  not  shown,  edge  label  [ti.fy]  is  a  short  hand 
notation  for  multiple  edges  ti, . . . , 

GCSR  Specification.  Figures  6  and  7  show  the  extended  BNF  for  GCSR.  We  use  the 
following  convention  for  extended  BNF:  A  production  (e.g.  A  ==  B)  has  a  name  (A)  and  a 
right  hand  side  describing  its  components  (B).  The  labels  N,  L, ...  etc.  aie  used  as  name  tags 
to  identify  the  component  of  the  production.  The  asterisk  is  used  to  denote  a  list /sequence 
(e.g.  A  ==  B*  means  A  is  a  list  of  B  elements).  Double  asterisks  aure  used  to  denote  a  set 
(e.g.  A  ==  B”  means  A  is  a  set  of  B  elements).  The  semi-colon  (e.g.  A  ==  B  ;  C)  is  used 
to  aggregate  components  in  a  production  (A  has  two  components  B  and  C).  The  vertical  bair 
(e.g.  A  =  B  I  C)  is  used  to  denote  choice  in  a  production  (A  has  either  component  B  or  C). 

A  GCSR  specification  is  a  component,  which  is  a  set  of  connected  nodes,  one  of  which  is 
a  designated  initial  node.  A  GCSR  component  also  has  attributes  consisting  of:  an  optional 
name,  a  set  of  resources,  and  a  set  of  observable  events. 

Since  a  complex  Box  node  has  other  nodes  nested  inside,  we  distinguish  between  levels 
at  which  a  node  resides  and  at  which  its  components  reside.  A  complex  Box  “encapsulates” 
tlw  nodes  it  contains  inside,  and  makes  them  unaccessible  from  outside  its  boundaries.  That 
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GCSRComponent  ==  N 

GCSRNode-’; 

I 

GCSRNode; 

L 

Link”; 

A 

Attributes 

Attributes  ==  Name 

Identifier; 

Resource 

Identifier”; 

Observ 

Identifier 

GCSRNode  ==  Name 

Identifier; 

Nil 

NilNode 

1  Dot 

DotNode 

1  Box 

BoxNode 

BoxNode  ==  Prim 

PrimitiveNode 

1  Cmplx 

ComplexNode 

1  Ref 

ReferenceNode 

NilNode 

NULL 

DotNode  == 

NULL 

ReferenceNode  == 

NULL 

PrimNode  ==  Resource 

GeneralldSet 

ComplexNode  ==  Resource 

GeneralldSet; 

Close 

GeneralldSet; 

Observ 

GeneralldSet; 

Restrict 

GeneralldSet; 

Inside 

GCSRComponent* 

Link  ==  S 

GCSRNode; 

T 

GCSRNode; 

Label 

IntemalExit  |  ExtemalExit 

IntemalExit  == 

Event 

ExtemalExit  == 

Time  |  Event  1  NULL 

Figure  6:  Extended  BNF  for  GCSR 
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Identifier 

STRING  1  IndexedVar; 

IndexedVar 

=  = 

STRING;  Index 

GeneralldSet 

=  =Z 

STRING”  1  IndexedVar 

Index 

=  = 

Min;  Max;  Step;  Matsk 

Min 

=  = 

integer  expression 

Max 

=  = 

integer  expression 

Step 

=  = 

integer  expression 

Mask 

=  = 

boolean  expression 

Event 

=  = 

STRING 

Time 

=  = 

INTEGER  1  (30 

Figure  7:  Extended  BNF  for  GCSR  (continued) 


is,  the  nodes  inside  a  complex  Box  node  in  a  component  belong  to  a  different  component 
from  the  one  to  which  the  complex  Box  belongs,  one  that  is  inside  the  complex  Box  node. 
Thus,  the  edges  listed  in  the  Link  set  (Figure  6)  of  a  GCSR  component  connect  only  nodes 
that  are  at  the  same  level  as  the  initial  node  of  the  component. 

Note  that  it  is  possible  to  transfer  out  of  a  nested  node  to  a  node  adjacent  to  its  ancestor 
node  using  an  internal-exit  edge.  That  is,  our  level  restriction  is  “syntactic”,  not  “semantic”, 
restriction  to  prevent  the  crowding  of  edges  in  GCSR  specifications. 

3.2  Valid  GCSR  Specification 

Obviously,  not  all  possible  GCSR  specifications  represent  valid  ACSR  specifications.  We 
now  define  a  set  of  criteria  for  a  GCSR  specification  to  be  valid. 

Nil,  Dot,  primitive  Box,  and  reference  Box  nodes  are  the  basic  nodes  that  do  not  contain 
an  internal  structure  inside.  A  complex  Box  node  contains  internal  components.  A  GCSR 
specification  can  be  built  from  these  nodes  according  to  the  following  definition. 

Definition  3.1  A  GCSR  valid  component,  (W, /,I,A),  is  a  connected  graph  that  consists 
of  a  set  of  nodes,  N,  one  of  which  is  a  designated  initial  node,  /  €  iV,  and  the  connection 
edges,  X,  and  attributes,^,  satisfying  the  following  rules: 

1.  Any  Nil  node  does  not  have  an  outgoing  edge;  that  is,  a  Nil  node  is  always  a  sink  node: 
V/€X:  l.S.type^Nil 

2.  Any  Dot  node  has  at  least  one  outgoing  event  or  unlabeled  edge  that  connects  it  to 
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another  node  at  the  same  level,  i.e.  without  crossing  any  node’s  boundaries: 

Vn  €  ^  :  if  n.type  =  Dot  then  31  e  L  :  l.S  =:  n 

3.  Any  Box  node  can  have  at  most  one  outgoing  edge  labeled  with  time,  and  possibly 
several  outgoing  event-labeled  or  unlabeled  edges  and  external-exit  edges  that  connect 
it  to  other  nodes  at  the  same  level: 

Vn  6  iV  i  if  n.type  —  Box  then  V/  €  :  {{l.S  =  n  A  l.type  =  Time)  — (V/'  e 

L  —  {1}  :  l.S  n  V  l.type  Time)) 

4.  For  each  complex  Box  node,  the  GCSR  components  inside  must  be  valid  and  do  not 
share  nodes: 

Vn  6  iV  :  if  {n.type  =  Cmplx  A  n.Inside  =  then  (VI  <  i  <  k  : 

Gi  isvaUd  )  A  (VI  <  i  <  ifc :  VI  <  j  <  ifc ;  {i^j—*  Ni  D  Nj  =  0)) 
where  VI  <  »  <  fc  :  G,  =  (A,,/„Z,i,  A,) 

5.  Attributes  are  valid  as  follows: 

Ntune:  All  component’s  names  are  unique. 

Resource:  The  Resource  set  of  a  complex  Box  node  is  the  union  of  the  Resource  sets  of 
its  subcomponents: 

Vn  €  JV  :  if  {n.type  =  Cmplx  ^n.Ineide  =  {Gi,.,.,Gfc})then  n.Resource  =  Ai-ResourceU 
...  U  A2.Rtscurce 

where  VI  <  i  <  fc  :  Gi  =  {Ni,  li,  Li,  Ai) 

The  Resource  set  of  a  component  is  the  union  of  all  the  Resource  sets  of  its  Box  nodes. 

A.Resource  —  |J  n.Resource 

n^N  ^■n.type=Box 

Observ;  The  observable  event  set  (Observ)  of  a  complex  Box  node  is  a  subset  of  the  Observ 
sets  of  its  subcomponents.  (The  additional  observable  events  can  be  used  to  synchronize 
among  the  subcomponents  inside  the  Box.) 

Vn  €  iV  :  if  {n.type  =  Cmplx  A  n.Inside  =  {Gi,..., Gfc})then  n.Observ  C  {Ai.Observ  U 
...  U  Ak.Observ) 

where  VI  <  t  <  fc  :  Gi  =  {Ni,  U,  Li,  Ai) 
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The  Observ  set  of  a  component  is  the  set  of  events  labeling  its  edges  {in  L)  union  the 
Observ  sets  of  its  complex  and  reference  Box  nodes: 

A.Observ  =  |J  n.Ohserv  U  |J  1. Label 

nCA^An.fypesCmp^z  l^L^l.typesEvent 

Rectrict:  The  restrict  event  set  (Restrict)  of  a  complex  Box  node  is  a  subset  of  the  Observ 
sets  of  its  subcomponents: 

Vn  €  iV  :  if  {n.type  =  Cmplx  A  n. Inside  =  {Gi,...,Gfc})then  n. Restrict  C  (Ai. Observ  U 
...  U  Ak‘Observ) 

where  VI  <  i  <  Jb  :  Gi  =  {Ni,  /,,  i,,  Ai) 

Observ  U  Restrict:  All  events  inside  a  complex  Box  are  accounted  for: 

Vn  €  AT  ;  if  {n.type  =  Cmplx  A  n. Inside  =  {Gi,...,G*})then  {n.Observ  U  n. Restrict)  = 

{Ai.Obaerv  U  ...  U  Ak.Observ) 

where  VI  <  t  <  i  :  Gj  =  {N,,  /,,  Li,  Ai) 

Reference  node:  The  attributes  of  a  reference  Box  are  those  of  the  GCSR  component 
that  defines  it. 

These  above  validity  criteria  are  needed  to  define  the  semantics  of  a  GCSR  component 
using  ACSR. 

3.3  Informal  GCSR  Semantics 

In  this  section  we  first  describe  informally  the  semantics  of  GCSR,  then  the  translations 
between  ACSR  and  GCSR.  These  translations  assume  that  ACSR  is  augmented  with  a 
binding  operator  that  binds  a  process  term  to  a  process  name,  generalized  parallel  2ind 
choice  operators,  as  well  as  indexed  variable  names. 

A  GCSR  (valid)  component  specifies  the  sequential  flow  of  control  among  nodes  repre¬ 
senting  units  of  work  (Box  nodes)  and  points  of  undelayed  communication  or  control  switch 
(Dot  nodes).  In  our  formalism,  work  is  represented  in  terms  of  resource  and  time  usage.  Con¬ 
trol  flow  in  a  GCSR  component  is  indicated  through  directed  edges  connecting  the  nodes. 
Complex  Box  nodes  allow  compact  specification  of  concurrent  components  as  well  as  execu¬ 
tion  nf  a  component  under  the  control  of  the  environment  which  can  interrupt  it  and  time 
it.  Finally,  nondeterministic  execution  is  represented  by  multiple  edges  out  of  a  (non  Nil) 
node. 
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Nodes.  A  unit  of  work  is  represented  by  a  Box  node.  It  can  represent  either  simple  resource 
and  time  consumption  (primitive  Box),  or  multiple  (or  one)  units  of  work  that  are  executed 
in  parallel  (complex  Box)  smd  possibly  under  the  (external)  control  of  the  environment  which 
can  time  their  activation  and  interrupt  it.  A  complex  unit  of  work  can  also  relinquish  control 
any  time  during  its  activation  and  indicates  the  direction  of  the  control  flow;  we  call  this  type 
of  control  flow  internal-exit,  since  the  complex  unit  of  work  internally  ends  its  activation,  as 
opposed  to  being  interrupted  by  its  environment.  This  explains  the  two  types  of  edges  in 
GCSR.  In  ACSR  terminology,  a  simple  unit  of  work  is  am  action,  while  a  complex  unit  of 
work  is  a  process. 

As  an  example,  consider  the  railroad  crossing  example  of  Figure  20.  The  Box  nodes  with 
the  empty  set  inside  represent  simple  units  of  work,  idling,  where  no  resources  are  used. 
In  the  specification  of  the  Gate,  the  complex  work  representing  opening  the  gate  can  be 
interrupted  by  the  event  signaling  to  start  closing  the  gate  (sdn),  or  can  finish  its  activation 
and  proceeds  to  the  initial  state  of  Gate  through  the  internal  exit  signal  open. 

The  second  type  of  nodes.  Dot  nodes,  represent  two  specification  scenarios.  The  first  is  a 
specification  point  where  an  event  must  be  produced  with  no  delay;  this  is  represented  by  an 
event  labeled  outgoing  edge.  The  second  is  a  specification  point  where  a  unit  of  work  must 
be  started  with  no  delay;  this  is  represented  by  an  unlabeled  outgoing  edge  whose  target 
node  is  a  Box  or  Nil  node.  For  example,  consider  again  the  Gate  GCSR  component  in  the 
nulroad  crossing  example  of  Figure  20;  the  initial  node  is  a  Dot  node  with  two  outgoing 
edges.  This  represents  a  point  where  either  the  idling  unit  is  started  or  the  event  adn  is 
produced;  the  choice  among  the  two  possibilities  is  made  at  the  instant  when  the  initial  Dot 
node  is  activated,  and  it  depends  on  the  enviroiunent. 

Node  activation.  When  a  GCSR  component  is  activated,  control  enters  its  initid  node. 
The  flow  of  control  stops  when  it  reaches  a  Nil  node,  at  which  time  the  whole  GCSR  com¬ 
ponent  is  deactivated.  The  activation  of  a  primitive  Box  node  is  subject  to  the  availability 
of  its  resources.  Finally,  when  a  complex  Box  is  activated  all  its  subcomponents  are  simul¬ 
taneously  activated  and  remain  active  for  the  same  period  of  time.  In  the  railroad  crossing 
example  of  Figure  20,  the  Train,  Control,  and  Gate  are  all  activated  the  instant  the  Railroad 
GCSR  component  is  activated.  Since  there  are  no  edges  out  of  the  initial  node  of  Railroad, 
this  latter  remains  active  as  long  as  its  subcomponents  remun  so. 
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Unlabeled  edge.  An  unlabeled  edge  is  taken  instantaneously  if  it  leads  to  a  node  that 
can  be  activated.  Such  an  edge  aillows  sequential  composition  of  different  types  of  nodes; 
that  is,  it  is  used  to  describe  a  sequential  execution  where  the  next  component  is  either  a 
complex  (complex  Box  node)  or  a  simple  resource  and  time  consuming  component  (primitive 
Box  node.)  Unlabeled  edges  allow  compact  construction  of  specifications. 

Event  labeled  edge.  An  event  labeled  edge  that  links  a  Dot  node  to  another  node  is  taken 
the  instant  the  source  Dot  node  is  activated  and  if  the  environment  allows  the  production 
of  the  labeling  event.  An  event  edge  out  of  a  Box  node  is  taken  any  time  the  environment 
allows  the  production  of  the  event  and  while  the  source  Box  node  is  active;  this  represents 
an  interrupt  and  has  a  higher  priority  than  edges  inside  the  source  Box  node.  The  tr2msition 
results  in  producing  the  event  labeling  the  edge. 

Time  labeled  edge.  An  edge  labeled  with  time  (t)  represents  the  time-guarded  execution 
of  work  represented  by  the  source  Box  node.  Once  the  source  Box  node  is  activated,  control 
remains  there  exactly  t  time  units  after  which  it  is  instantaneously  transferred  to  the  target 
node  of  the  time  edge.  It  is  important  to  note  that  the  source  Box  node  must  remain 
constantly  active  for  the  t  units.  If  it  requires  more  than  t  time  units,  it  is  aborted;  on  the 
other  hand,  if  it  executes  for  less  then  t  time  units,  the  timed  edge  will  not  be  taken.  A 
timed  edge  is  also  a  type  of  interrupt  and  hence  has  a  higher  priority  than  edges  inside  the 
source  Box  node. 

Internal-exit  edge.  Any  time  during  its  activation,  the  source  Box  node  can  produce  the 
exit  event  to  signal  internal  end  of  execution.  Control  is  then  instantaneously  transferred 
to  the  target  node  of  the  internal-exit  edge.  The  internal  exit  event  is  a  type  of  local 
synchronization  between  the  internal  structure  of  the  Box  source  node  and  its  interface;  that 
is,  this  event  is  not  visible  anywhere  else  in  the  system. 

It  is  important  to  note  that  control  remains  a  non  zero  amount  of  time  only  inside  Box 
nodes,  and  that  all  transitions  are  instantaneous.  The  activation  of  the  target  node  of  a 
takra  tr^m8ition  might  be  subject  to  the  environment.  For  example,  if  the  target  node  is  a 
primitive  Box  node  whose  resources  are  not  available  the  instzmt  the  transition  is  taken,  the 
system  enters  a  deadlocked  state  after  the  transition  is  taken. 

Modularity.  Modularity  is  supported  in  GCSR  through  the  visibility  scope  of  the  commu¬ 
nication  events.  The  set  of  observable  events  of  a  GCSR  component,  are  visible  everywhere. 
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On  the  other  hand,  the  set  of  restricted  events  in  a  complex  Box  node  are  used  for  loczd 
synchronization  among  components  inside  the  Box,  and  hence  are  not  visible  elsewhere  out¬ 
side  the  Box’s  boundaries.  Such  a  scoping  rule  has  the  advantage  of  limiting  dependencies 
among  nodes  in  a  GCSR  specification.  This  advantage  is  important  in  a  hierarchical  design 
of  a  real-time  system. 

3.4  Formal  GCSR  Semantics 

Figure  8  shows  the  translation  of  ACSR  terms  to  a  GCSR  component  based  on  structure  of 
the  ACSR  terms.  Figure  9  shows  the  translation  of  the  binding  operator,  indexed  variables 
as  well  as  generalized  parallel  and  choice  operators.  The  function  g{-)  translates  an  ACSR 
term  to  a  GCSR  component. 

Note  that  the  direct  translation  of  ACSR  terms  does  not  create  a  GCSR  graph  where 
a  Box  node  has  an  edge  labeled  with  an  event  or  a  Box  node  with  multiple  event  egdes. 
Such  a  graph  can  however  be  obtained  through  the  simplifications  described  in  Figure  10. 
Also,  note  that  the  translation  of  an  ACSR  term  to  a  GCSR  component  does  not  introduce 
cycles.  Gr«^>hical  reductions  as  described  in  Figure  12  allow  the  simplification  of  the  graph 
and  creation  ot  cycles. 

GrojAieal  reductions.  We  divide  graphical  reductions  into  two  classes.  Figures  10  and  11 
show  simple  graphical  reductions  that: 

1.  merge  'identical’’  portions  of  the  graph; 

2.  remove  unnecessary  unlabeled  edges  that  can  be  due  to  unnecessary  parenthesis  in  the 
ACSR  process; 

3.  remove  edge  labeled  with  infinity  and  its  NIL  target  node; 

4.  merge  consecutive  ‘‘identical”  activities;  this  applies  the  time  additivity  property  of 
ACSR; 

5.  remove  extra  structure  inside  a  Box,  that  denote  recursive  usage  of  resources;  this  is 
due  to  the  fact  that  time  is  discrete  in  ACSR; 

6-7.  remove  extra  Box  node  nesting  that  can  be  due  to  resolving  Reference  Box  nodes  or 
unnecessary  parenthesis  in  the  ACSR  process;  (This  simplification  rule  aiso  msikes  use 
of  the  ACSR  Clo6e(5)  and  Rest(6)  laws  [6].) 


Figure  9:  ACSR  to  GCSR  translation 
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Figture  10:  GCSR  simple  graphical  reductions  and  short  hand  notations. 
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Figure  11:  GCSR  simple  graphical  reductions  and  short  hand  notations  (continued) 


8-9.  give  a  template  representation  as  a  short  hand  notation  for  generalized  ACSR  pareillel 
and  choice  operators. 

Figure  12  shows  more  complex  graphical  reductions  to  resolve  Reference  Box  nodes  by  1) 
binding  them  to  a  node,  or  2)  replacing  them  with  the  process  definition  (unfolding).  Top, 
sink  reference  nodes  in  Figure  12  are  bound  to  the  initial  node  of  the  corresponding  process. 
This  reduction  is  allowed  only  if  the  reference  node  and  the  initial  node  of  the  corresponding 
process  are  at  the  same  level.  Bottom,  a  reference  Box  is  replaced  by  the  GCSR  component 
defining  it.  Further  reductions  would  be  based  on  the  ACSR  laws. 

To  define  the  semantics  of  GCSR,  we  have  developed  an  algorithm  that  translates  a 
GCSR  component  to  an  ACSR  term.  This  translation  assumes  some  validity  criteria  of 
GCSR  components.  These  criteria  are  described  in  Section  3.2. 

4  Examples 

In  this  section  we  present  several  examples  of  GCSR  specifications  and  their  corresponding 
ACSR  processes.  We  use  the  railroad  crossing  example  to  illustrate  how  some  of  the  graph¬ 
ical  reductions  described  in  the  previous  sections  can  be  applied.  We  do  not  show  all  the 
attributes  to  make  the  figures  more  readable,  and  we  list  the  resource  set  inside  primitive 
boxes. 

Telephone.  Figure  13  shows  the  GCSR  specification  of  a  telephone  system  and  its  corre¬ 
sponding  .ACSR  specification.  The  phone  is  initially  idle  until  it  receives  the  signal  that  the 
receiver  is  o/ fhook.  At  this  time,  the  user  has  20  time  units  to  dial  the  first  digit  (signaled 
by  the  reception  of  digit.)  If  the  user  fails  to  di2d  the  first  digit  within  the  20  time  unit 
deadline,  a  the  phone  produces  a  reorder  signal  and  returns  to  its  initied  state.  If  the  user 
dials  the  first  digit  within  the  deadline,  he/she  must  dijd  the  remaining  four  digits  within  15 
time  units  relative  to  dialing  the  first  one.  An  additional  timing  constraint  on  the  last  four 
digits  is  that  any  two  consecutive  digits  must  be  dialed  in  less  them  five  time  units  apart. 
Any  time  this  timing  constraint  is  violated,  the  phone  issues  a  reorder  signal  and  returns 
to  its  initial  state.  On  the  other  hand,  if  the  last  four  digits  are  dialed  according  to  this 
deadline  and  within  the  15  time  units  from  the  first  digit,  the  phone  issues  a  connect  signal 
and  allows  the  user  to  talk.  When  the  user  puts  the  receiver  on  the  hook  again  (signaled  by 
the  re^ception  of  onhook)  the  phone  returns  to  its  initial  state. 
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IDLE  , 


Phone  =  IDLE  C,^{NIL,NIL,{offkook,\).OH) 

OH  =  IDLE  ^^{NIL, {reorder, l).Phone,{digtt,l)Digits) 

Digits  =  Z?[l]  Ajj  *  '**  ”  {{reorder, \). Phone  +  Talk,  {reorder,  l).Phone,  NIL) 

!>[*■]  =  IDLE  As  {NIL,  {reorder,  l).{cancel,  1).NIL,  {digit,  l).P[i  +  1])  1  <  i  <  4 

D[5]  =  {exit2,l).NIL 

Talk  =  (connect,  1).{IDLE  A^  {NIL,  NIL,  {onhook,  l).Phone)) 


Figure  13:  Telephone  Example. 


Mouse.  Figure  14  shows  the  GCSR  and  corresponding  ACSR  specification  of  a  mouse 
example.  The  mouse  is  initially  idle  until  its  button  is  pressed  down  {down  event  is  received.) 
This  is  the  beginning  of  a  click  that  might  be  followed  by  another  clock  to  signal  a  double 
click.  A  single  click  consists  of  pressing  the  mouse  button  down  then  up.  A  double  click 
consists  of  two  consecutive  single  clicks  that  happen  within  500  time  units  and  such  that  the 
down  and  up  of  each  single  click  are  less  then  200  time  units  apart.  Each  time  the  mouse 
button  is  pressed  down  for  200  time  units  or  more,  the  mouse  signals  hold,  then  when  the 
button  is  pressed  up  the  mouse  signals  release  eind  returns  to  its  initial  state.  The  mouse 
also  signals  either  click  or  doubleclick  according  to  whether  a  signal  click  or  double  clicks 
happened. 

Railroad  Crossing.  Figure  15  shows  the  ACSR  specification  of  the  standard  Railroad 
crossing  system  with  fixed  parameters.  The  system  consists  of  a  train  (Train),  a  controller 
(Control)  and  a  gate  (Gate),  that  coordinate  their  activities  through  the  synchronization 
events  3rn,sdn,sup,  and  srp.  The  detailed  description  of  this  example  can  be  found  in  [7]. 
Figure  16  shows  the  direct  translation  of  ACSR  specification  to  GCSR,  and  Figures  17-19 
show  how  the  GCSR  specifications  can  be  simplified  using  graph  reductions.  The  steps  are: 
Figure  17  shows  1)  Unfolding  applied  to  Train,  Treun’,  Gate  and  GD’;  the  reference  nodes 
were  replaced  by  their  corresponding  process  graph.  2)  Unfolding  applied  to  all  references  to 
IDLE,  then  the  simple  reduction  where  the  recursive  consumption  of  no  resources  is  replaced 
by  a  primitive  Box  with  no  resources  (reduction  number  4).  3)  A  simple  reduction  in  GU 
where  the  infinity  time  edge  with  target  NIL  was  removed(reduction  number  2).  In  Figure 
18,  further  unfolding  step  is  applied  on  Trun  and  Gate  of  the  railroad  crossing  example  of 
Figure  17,  Figure  19  demonstrates  further  unfolding  applied  on  Train,  Gate  amd  Control  of 
the  railroad  crossing  example  of  Figure  18.  The  reference  nodes  have  naunes  of  nodes  that 
are  paurt  of  the  graph  amd  at  the  samie  level.  They  aire  removed  amd  their  incoming  edges  are 
bound  to  the  actual  node.  Finally,  adl  reference  nodes  axe  removed  in  Figure  20. 

Sensor.  Figure  21  shows  the  GCSR  specification  of  a  Senor  system.  It  consists  of  a  data 
reading  unit  (ReadSensor)  amd  a  data  processing  unit  (Server),  that  communicate  through 
a  shared  buffer  (B).  Mutual  exclusive  access  to  the  buffer  is  enforced  by  a  binary  semaphore 
(Semaphore.)  ReadSensor  accumulates  data  for  three  time  units,  then  averages  it  in  one 
time  unit,  amd  stores  it  into  the  buffer  in  two  time  units.  Server  is  initiadly  for  six  time 
units,  to  avoid  reauling  out  of  an  empty  buffer.  Once  active.  Server  wauts  for  a  read  signal 
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Figure  14:  Mouse  Example. 
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Figiire  15:  Rail  Road  Crossing  Example  ACSR  Specification 
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Figure  17:  Example  of  graphical  reductions  applied  to  the  example  of  Figure  16 
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Figure  18:  Further  unfolding  applied  on  Train,  Gate  of  the  example  of  Figure  17. 

at  which  time  it  tries  to  get  access  to  the  buffer  to  copy  the  value  from  the  buffer  to  a  display 
(D);  copying  and  displaying  the  data  takes  each  one  unit  unit.  Further  simplifications  on 
the  initial  nodes  of  Server  and  ReadSensor  are  possible. 

Router.  Figure  22  shows  the  GCSR  and  corresponding  ACSR  specifications  of  a  router’s 
specification  Router  Spec  and  implementation  Router  Imp.  The  router  is  initially  idle  until  it 
receives  datain  signal.  It  then  reads  the  data  in  one  time  unit,  tries  to  send  in  two  time  units 
at  which  time  it  signals  an  acknowledgement  ack,  then  waits  one  time  unit  before  returning 
to  its  initial  state.  The  implementation  of  the  router,  Routerimp,  shows  the  details  of  the 
sending  unit.  It  consists  of  a  unit  to  prepare  the  datagram  for  transmission,  synchronizing 
with  a  unit  that  gets  transmission  permission.  If  the  router  has  permission  to  forward  the 
datagram,  it  carries  the  send  in  one  time  unit  and  signals  a  success  acknowledgement,  other 
wise  it  executes  an  error  handler  routine  and  signals  failure. 
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Figure  20:  Railroad  Crossing  Example: 


ObMCV«(lMd) 
RenMuce  a(AJkO^) 


Initial  Box  Antiboies: 
ObtRV  « (mod) 
RcarictK  {wiit,ii(Bal| 
ReM>aic«>(A3.0,S) 


Figure  21:  Sensor  Example.  Reference  nodes  have  been  replaced. 


RouterSpec 
Router  Imp 
Process 
Process’  = 


=  IDLE  Aqo  (NIL,NIL,dataIn.(l,ReadStep):(2,SendStep):ack.{}:RouterSpec) 
=  IDLE  (NIL,NIL,dataIn.(l,ReadStep):Process) 

=  Process’  A3  (NIL,  Routerimp,  NIL) 

((l,PrepareTransmit):  (granted.(l,CaxrySend):success.(cc,{}):NIL  + 

denied.(l,Error):failure.(oo,{  }  ):NIL) 


11 

( 1  ,Get  Permission )  : 


(granted.(oo,{}):NIL  + 
denied:(oo,{}):NIL))  \  {granted,  denied} 


Figure  22:  Router  Example 
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5  Automatic  Analysis  Techniques 


To  support  the  automatic  analysis  of  GCSR  specifications,  we  have  investigated  state  min¬ 
imization  algorithms  and  verification  techniques  that  we  plan  to  implement.  Section  5.1 
briefly  explains  the  state  minimization  algorithm  we  plan  to  implement.  Section  5.2  identi¬ 
fies  a  set  of  equivalence  relations  that  are  weaker  than  the  ones  we  currently  have.  We  believe 
that  these  weaker  notions  are  much  more  practical  than  our  current  notions  of  prioritized 
strong  and  weadc  bisimulations.  Section  5.3  describes  logic  that  we  have  designed  to  facilitate 
the  partial  specification  (i.e.,  requirement  specification)  and  model  checking  of  ACSR. 

5.1  State  Minimization  Algorithms 

One  of  the  goals  of  this  project  is  to  identify  efficient  algorithms  for  the  automated  verifica¬ 
tion  of  distributed  real-time  systems  based  on  state  space  exploration.  There  exist  several 
automatic  verification  techniques  for  finite  state  systems.  Such  techniques  cire  usually  based 
on  state  space  exploration.  That  is,  they  first  identify  a  set  of  states  that  are  reachable 
from  the  initial  states  and  then  analyze  this  set  for  verification.  They  are  used  for  proving 
absence  of  deadlock  or  livelock,  for  proving  properties  expressed  in  propositionad  temporal 
logic  or  real-time  logic,  and  for  determining  traw:e  equivalence,  testing  preorder  or  bisimula¬ 
tion  equivalence,  etc. 

There  exist  several  state  minimization  2dgorithms  for  a  labeled  transition  system  that 
collapse  a  set  of  states  that  are  bisimilar  into  an  equivalent  class  [17,  33].  These  algorithms 
require  the  generation  of  the  entire  state  space,  including  unre£u;hable  states.  Thus,  they  can 
be  applied  only  to  systems  with  a  finite,  relatively  small  state  space.  It  would  be  desirable  to 
explore  only  the  reachable  portion  of  the  state  space.  Bouajjeini  et  al.  have  developed  such 
an  algorithm  to  find  the  minimal  reachability  graph  for  unlabeled  transition  systems  [5].  The 
algorithm  performs  reachability  analysis  and  minimization  simultaneously.  This  algorithm 
is  very  effective  when  the  reachable  portion  is  much  smaller  than  the  full  state  space.  But, 
unlabeled  transition  systems  used  by  them  are  not  suitable  for  describing  concurrent  systems 
since  they  cannot  capture  internal  actions  and  communication  actions.  Our  algorithm  is  an 
extension  of  the  algorithm  by  Bouajjani  et  al.  [5]  to  a  labeled  tremsition  system. 

The  basic  idea  of  minimizing  a  transition  .system  is  to  find  a  partition  of  states  such  that 
all  the  states  in  each  class  of  the  partition  are  bisimilar  zind  all  bisimilar  states  are  in  the 
same  class.  The  following  describes  the  basic  idea  of  our  algorithm  [18]: 

repeat 
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pick  a  reachable  class  X ; 
if  s  y  and  s'  for  s,  s'  €  JV  then 
split  X 

until  no  more  splits  possible 

Starting  from  the  class  consisting  of  the  entire  states  as  the  sole  member  of  the  initial 
partition  (that  is,  po  =  {^3}))  the  algorithm  tries  to  iteratively  split  classes  in  the  current 
partition  until  it  is  no  longer  possible.  The  splitting  procedure  keeps  states  in  the  same 
class  until  they  are  shown  to  be  non- bisimilar.  Such  a  class  is  called  stable  with  respect  to 
the  current  partition  in  the  algorithm.  In  other  words,  for  a  given  initial  partition  po,  the 
algorithm  repeatedly  split  classes  that  ane  not  stable  with  respect  to  the  current  partition 
until  the  coarsest  stable  partition  is  found.  The  coarsest  stable  partition  is  equal  to  the 
greatest  bisimulation.  We  note  the  algorithm  may  not  always  terminate.  It  terminates  only 
when  the  greatest  bisimulation  has  finite  number  of  equivalence  classes. 

Figure  23  gives  the  comparison  of  the  .osults  of  the  Paige  and  Tarjan’s  algorithm  [33] 
and  our  algorithm.  The  partitions  are  the  same  except  for  unreachable  state  space.  But, 
Paige  and  Tarjan's  algorithm  explores  the  whole  set  of  states  including  unreachable  states. 
Thus,  our  algorithm  is  based  on  a  more  efficient  algorithm  for  the  edgorithm  developed  by 
Paige  and  Tarjan. 


(a )  The  Result  of  Paige  and  Taijan’s  Algorithm  (b  )  The  Result  of  Our  Algorithni 

Figure  23:  The  Coarsest  Partition 
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5.2  Additional  Equivalence  Relations  for  ACSR 

Strong  equivalence  is  a  useful  notion  for  compeirison  of  agent  expressions,  but  for  many  prac¬ 
tical  applications  weaker  forms  of  equivalence  suflBce.  The  need  to  weaken  the  requirement 
regarding  exact  matching  of  r  actions  is  well  known,  but  ACSR  introduces  several  other 
areas  where  requiring  strict  equivalence  between  expressions  is  cumbersome.  For  example, 
although  precise  priority  values  are  required  for  each  event  and  resource  in  an  action,  fre¬ 
quently  it  is  the  case  that  the  relative  priority  levels  are  more  important  than  the  exact 
values. 

The  sections  that  follow  will  detail  a  number  of  equivalence  relations  weaker  them  strong 
bisimulation,  but  perhaps  more  useful  for  comparison  of  realistic  implementations  and  specifi¬ 
cations.  In  the  remainder  of  this  section,  terms  used  throughout  the  definitions  of  equivalence 
are  presented. 

Definition  5.1  (Substitution  of  Terms)  The  agent  expression  A{EIX),  where  A  and  E 
are  agent  expressions  and  X  is  a  process  variable,  shall  denote  the  agent  resulting  from  the 
syntactic  substitution  of  agent  expression  E  wherever  X  occurs  free  in  A. 

Definition  5.2  (Sequential  ACSR)  Full  ACSR’s  sequential  combinators  form  an  algebra 
that  we  shall  refer  to  as  sequential  ACSR.  It  has  the  following  syntax: 

P  ::=  NIL  |  A  :  P  j  {a,n).P  |  P  +  P  |  recX.P  \  X 

The  semantics  of  each  of  the  operators  is  identical  to  the  meaning  assigned  in  full  ACSR, 
including  the  definitions  of  preemption  and  prioritized  transitions. 

5.2.1  LTS  Based  Equivalences 

Unprioritized  Congruence.  Although  priorities  are  important  for  mediating  competi¬ 
tion  for  resources  and  implementing  preemption  based  synchronization,  the  final  determina¬ 
tion  as  to  whether  or  not  two  agent  expressions  are  equivalent  is  likely  to  have  more  to  do 
with  the  sequence  of  event  labels  and  resource  allocations  generated  than  with  the  precise 
priority  value  associated  with  each  event  emd  resource.  For  example,  consider  the  following 
processes; 


P  =  (a,l).(T,l).(b,l).NIL 

Q  =  ((a,l).(sync,l).NILII(sync,l).(b,l).NIL)\{sync} 
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Since  P  and  Q  generate  the  same  traces  of  event  labels  (a,  then  t,  and  then  6),  it  is  appealing 
to  consider  them  equivalent  in  some  sense.  However,  the  semantics  of  synchronization  require 
that  the  resulting  r  event  be  assigned  the  sum  of  the  priorities  of  the  complementary  events. 
Therefore  P  Q  since  the  priority  of  the  r  step  in  P  must  be  2  if  P  and  Q  are  to  be 
strongly  bisimilar. 

One  way  to  address  this  problem  would  be  to  ignore  priorities  altogether  in  making  the 
comparison,  but  since  priorities  play  an  importan  role  in  defining  behaviors  within  an  agent, 
the  equivalence  relation  that  resulted  would  be  of  little  use.  Instead,  we  define  the  following 
equivalence  that  tempers  the  notion  of  priority-free  equiv«ilence  with  the  preservation  of 
relative  priority  within  agents. 

Definition  5.3  (Unprioritized  Equivalence:  =|«)  P  —^Q  iff,  for  all  a  &V, 

(i)  Whenever  P  P'  then,  for  some  Q'  and  ^  Q  -4,^  Q',  1(a)  =  /(/?)  (for  instanta¬ 

neous  events)  or  p{a)  =  p(0)  (for  timed  actions),  and  P'  Q'. 

(ii)  Whenever  Q  -5,  Q*  then,  for  some  P'  and  £  V,  P  P' ,  lia)  =  l{^)  (for 
instantaneous  events)  or  p(a)  =  p{3)  (for  timed  actions),  and  P'  =y  Q'. 

Proposition  5,1  Unprioritized  equivalence  is  an  equivalence  relation. 

Proposition  5.2  Unprioritized  equivalence  is  not  a  congruence  relation  for  sequential  ACSR. 

It  follows  directly  from  proposition  5.2  that  unprioritized  equivalence  is  not  a  congruence 
over  full  ACSR,  since  any  counterexample  formulated  in  sequential  ACSR  will  eilso  hold  for 
full  ACSR. 

Unprioritized  equivalence  fails  to  be  a  congruence  for  sequential  ACSR  because  of  the 
interaction  between  initial  prioritized  trsmsitions  and  trsinsitions  they  may  be  combined 
with  in  an  unprioritized  choice.  We  can  obtain  a  weaker  equivalence  that  is  a  congruence 
for  sequential  ACSR  by  requiring  equivalent  priorities  in  initial  prioritized  transitions. 

Definition  5.4  (Simple  Unprioritized  Congruence:  P  Q  iff,  for  all  a  eV, 

(i)  Whenever  P  P*  then,  for  some  Q\  Q  -5,  Q'  and  P'  =/  Q\ 

(ii)  Whenever  Q  -3,,  Q'  then,  for  some  P\  P  P*  and  P'  Q'. 

Proposition  5.3  Simple  unprioritized  congruence  is  an  equivalence  relation. 
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Proposition  5.4  Simple  unprioritized  congruence  is  a  congruence  relation  for  sequential 
ACSR. 


For  full  ACSR  the  situation  is  complicated  by  the  existence  of  operators  that  can  change 
priority  relationships  that  exist  deep  within  an  agent.  For  example,  consider  the  following 
processes: 

P  =  (ei,l).(c2,l).({(ri,0)}:Ri  +  {(r2,3)}:R2) 

Q  =  (ei,l).(e2,l).({(ri,3)}:Ri  +  {(r2,0)}:i22) 

5  =  [XUrur,) 

That  P  Q  follows  from  the  definition  of  simple  unprioritized  congruence  since  the  initial 
event  steps  are  identical  and  the  same  nondeterministic  choice  between  ri  ijxd  r2  exists  in 
both  P  and  Q.  However,  5{F\A’}  94^  5{Q\A’}  since  closure  with  ri  amd  r2  introduces 
preemptions  into  P  and  Q  eliminating  the  possibility  of  P  =»  Ri  and  Q  ^  R2. 

Proposition  5.5  Simple  unprioritized  congruence  is  not  a  congruence  relation  for  full  ACSR. 
Proof:  By  the  previous  counter-example.  □ 

To  simplify  the  definition  of  a  more  robust  unprioritized  congruence  we  first  define  the 
following  close  operator  for  sets  of  resource,  priority  pairs.  We  then  define  unprioritized 
congruence  in  two  steps,  the  first  addressing  potential  preemptions  that  could  arise  from 
application  of  the  ACSR  close  operator,  and  the  second  addressing  the  need  for  an  exact 
match  of  priorities  for  the  initial  step  of  a  process. 

Definition  5.5  Given  two  timed  actions  a  and  c/ose(a, /?)  will  represent  the  addition  of 
resource  and  priority  pairs  to  a  that  is  necessary  to  insure  that  1(a)  D  /(/3).  Formally, 

close(a,0)  =  {(r,p)((r,p)  e  Q  V  (r  /(q)  Ar  €/()?)  Ap  =  0)}. 

Definition  5.6  P^Q  iff,  for  all  a^V, 

(i)  Whenever  P  P'  and  -i3a'  €  "D  such  that  a  ^  a'  or  close{a,a')  -<  a'  and  P  ^  then, 
for  some  Q'  and  /3  G  P,  Q  Q'y  “*3/3'  €  V  such  that  ^  or  close{0, 0')  -<  0'  and 
Q  1(a)  =  1(0)  (for  instantaneous  events)  or  p(a)  =  p(0)  (for  timed  actions),  and 
P'^Q'. 
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(»)  Whenever  Q  Q‘  and  ->3a'  €  V  such  that  a  -<  a'  or  close(a,  q')  -<  a'  and  Q  ^  then, 
for  some  P'  and  /3  €'D.  P  P',  €  t>  such  that  0  ^  3*  or  close{3, 3')  ■<  3'  and 

P  l{ct)  =  l{3)  (for  instantaneous  events)  or  p{q)  =  p{3)  (for  timed  actioTis),  and 

Definition  5.7  (Unprioritized  Congruence:  «,»)  P  iff,  for  all  a  eV, 

(i)  Whenever  P  -3,  P'  then,  for  some  Q' ,  Q  -3,  Q'  and  P'^Q'. 

(ii)  Whenever  Q  -3,  Q'  then,  for  some  P' ,  P  P'  and  P'^Q'. 

Proposition  5.6  Unprioritized  congruence  is  a  congruence  relation. 

r-BVee  Congruence.  The  development  of  r-free  equivalence  for  ACSR  parallels  the  de¬ 
velopment  of  weak  bisimulation  (observation  equivzJence)  and  observation  congruence  in 
CCS[31].  We  begin  by  introducing  a  relation  which  allows  all  t  actions  to  be  ignored,  of¬ 
fering  an  equivalence  that  is  useful  for  comparing  complete  agents,  but  fails  to  satisfy  the 
requirements  for  a  congruence. 

As  in  CCS,  we  define  an  operator  to  “hide”  the  r  events  in  a  trace,  and  a  new  transition 
relation  that  allows  r  actions  to  be  abided  at  will. 

Definition  5.8  Ift  &  Ve',  then  i  6  Ve*  is  the  sequence  obtained  by  deleting  all  occurrences 
of  T  from  t. 

Definition  5.9  //t  =  oi  •  •  •  On  €  2^,  then  E  ^  E'  if 

We  shall  also  write  E  A'  to  mean  that  E  A  E'  for  some  E'. 

Definition  5.10  (r-Free  Equivalence:  =y)  P  =iQ  iff,  for  all  a  6  P, 

(i)  Whenever  P  -3,^  P'  then,  for  some  Q' ,  Q  Q'  and  P'  —y  Q' . 

(ii)  Whenever  Q  -3,  Q'  then,  for  some  P',  P  Ayr  P'  and  P'  =/  Q'. 

Proposition  5.7  r-free  equivalence  is  an  equivalence  relation. 


Proposition  5.8  r-free  equivalence  is  not  a  congruence  relation  for  sequential  ACSR. 


The  way  in  which  the  preemption  relation  is  defined  for  comparisons  between  r  events 
and  time  consuming  actions  greatly  simplifies  the  task  of  recasting  r-free  equivalence  as  a 
congruence  (as  compared  to  the  work  required  above  to  form  an  unprioritized  congruence 
from  unprioritized  equivalence).  Just  as  in  CCS,  initial  t  steps  must  be  preserved  if  nonde- 
tenninistic  choice  is  to  preserve  r-free  congruence.  But  unlike  unprioritized  equivalence,  the 
possibility  that  application  of  the  ACSR  close  operator  may  introduce  preemptions  where 
none  existed  before  is  immaterial,  since  any  nondeterministic  choices  that  exist  between 
time  consuming  action  steps  in  r-free  equivalent  processes  must  match  exactly,  so  introduc¬ 
tion  of  new  preemptions  through  the  close  operator  will  effect  all  r-free  equivalent  processes 
identically. 

Definition  5.11  (r-Free  Congruence:  wy)  P  «y  Q  iff,  for  all  a  €V, 

(i)  Whenever  P  -?,r  P'  then,  for  some  Q' ,  Q  Q'  and  P'  =y  Q'. 

(ii)  Whenever  Q  -3,  Q'  then,  for  some  P' ,  P  P'  and  P'  =y  Q'. 

Proposition  5.9  r-free  congruence  is  a  congruence  relation. 

Time-THggered  Congruence.  In  [20]  real-time  systems  are  subdivided  into  time-triggered 
and  event-triggered  models,  based  on  the  way  in  which  a  system  responds  to  its  inputs. 
Briefly,  time-triggered  systems  are  polling  systems,  in  which  inputs  are  accumulated  be¬ 
tween  polling  intervals  and  acted  upon  as  a  group  at  the  end  of  the  polling  interval  without 
regard  to  the  exact  ordering  of  received  events.  In  contrast,  event-triggered  systems  aire 
event  driven,  responding  immediately  upon  receiving  an  input.  Event-triggered  systems  can 
receive  2md  respond  to  a  potentially  infinite  stream  of  inputs  between  cycles  of  the  system 
clock. 

Although  ACSR’s  imderlying  model  is  event- triggered,  it  is  still  possible  to  use  ACSR  to 
represent  time-triggered  systems.  To  do  so,  the  author  of  a  specification  need  only  restrict 
their  processes  so  that  received  events  are  not  acted  upon  until  a  unit  of  time  has  elapsed, 
and  the  order  in  which  events  are  received  does  not  change  the  result  computed.  The  result 
of  this  restriction  is  that  the  order  of  event  occurrences  between  any  given  pair  of  time 
consuming  actions  becomes  immaterial,  since  the  events  that  happen  between  time  intervals 
are  predetermined  by  the  end  of  the  preceding  time  consuming  action.  For  example,  consider 
the  following  processes  for  h2uidling  out-of-paper  edarms  from  a  printer  process: 

PrintMonitor  —  recX. {(Paper Jam,  1).0  :  (SignalOperator,  l).{WriteLog,  1)..Y  + 
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ii:X 

) 

Print  Monitor'  =  recX.{{PaperJam,  1).0  :  {WriteLog,  l).{Signat(!)perator,  1)„Y  + 

9:X 

) 

No  notion  of  equivalence  that  hzis  been  presented  in  the  preceding  sections  could  be  used 
to  daim  that  these  two  processes  are  equivalent,  yet  from  a  time-triggered  point  of  view  they 
must  be,  since  the  ordering  of  SignalOptrator  and  WriteLog  will  not  change  the  operation 
of  any  time-triggered  agent  PrintMonitor  or  PrintMonitor'  could  be  composed  with.  Their 
behaviors  are  equivalent,  from  a  time-triggered  point  of  view. 

We  begin  the  definition  of  time-triggered  equivalence  with  two  preliminary  definitions 
that  will  simplify  the  formal  definitions. 

Definition  5.12  Ift  =  ((ci,Pi),(c3,p2),-..,(c«,p„))  €  Ve%  then  when  E  ••• 

E*  we  write  E  E'.  We  shall  also  write  E  to  mean  that  E  E'  for  some  E'. 

Definition  5.13  Given  an  event  trace  t  6  Dg",  the  set  of  unique  label  and  priority  pairs 
in  t  is  denoted  events{t). 

The  definition  of  time-triggered  equivalence  addresses  three  types  of  process  behaviors. 
For  two  processes  to  be  equivalent,  their  initial  untimed  event  sequences  must  match,  any 
event  sequences  between  corresponding  time  consuming  actions  must  match,  and  any  se¬ 
quences  of  untimed  events  that  lead  up  to  a  deadlocked  state  {NIL)  must  match.  (To 
‘‘match”  two  untimed  event  sequences  me2ms  that  they  must  be  made  up  of  the  same  set  of 
unique  {label, priority)  pairs,  although  order  and  duplication  is  not  significant.)  The  defini¬ 
tion  of  Action  Equivalence  addresses  the  second  and  third  conditions,  while  the  definition  of 
Time-Triggered  Equivalence  addresses  initial  sequences  of  untimed  events,  and  deadlocked 
traces  with  no  time  consuming  actions,  while  relying  on  the  definition  of  Action  Equivalence 
to  address  the  remaining  portions  of  traces. 

Definition  5.14  (Action  Equivalence:  =*«)  P  =oe  Q  iff,  for  all  Ai,A2  E  Vr  and  t  e 

t>E‘, 

(i)  Whenever  P  -4?,—+,  P'  then,  for  some  Q'  and  t'  6  Ve’,  Q  Q',  events{t)  = 

tvents{t'),  and  P'  =ae  Q'; 
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(ii)  Whenever  Q  Q'  -h?,  then,  for  some  P‘  and  t'  €  Pe",  P  P' ,  events{t)  = 

events{t'),  and  P*  =ae  Q'; 

(Hi)  Whenever  P  4?,-+,  P'  then,  for  some  Q'  and  t'  €  'De"‘,  Q  4,4,  Q'  an<i 
cucnt3(t)  =  events{t'). 

(iv)  Whenever  Q  4,-4,  Q'  /»,  fAen,  /or  some  P'  and  t'  €  P  4,-4,  P'  and 
events{t)  —  cucnts(P). 

Proposition  5.10  Action  equivalence  is  an  equivalence  relation. 

Definition  5.15  (Time-Triggered  Equivalence:  =u)  P  =u  Q  iff,  for  all  A  £  Vr  and 
t  €  Pe‘, 

(i)  Whenever  P  -4,  P'  -4,  then,  for  some  Q'  and  t'  £  T>e‘,  Q  4,  Q',  events(t)  = 
eventsif),  and  P'  =**  Q'; 

(ii)  Whenever  Q  4,  Q*  -4,  then,  for  some  P'  and  t'  £  Ve* ,  P  4,  P* ,  events{t)  — 
events(f),  and  P'  =««  Q'; 

(Hi)  Whenever  P  4,  P'  ^4,  then,  for  some  Q'  and  t'  £  Ve",  Q  4,  Q’  /»,,  and  events{t)  = 
events{t'); 

(iv)  Whenever  Q  4,  Q'  then,  for  some  P'  andt'  £  Ve" ,  P  4,  P'  /»,,  and  events{t)  = 
events{tr). 

Proposition  5.11  Time-triggered  equivalence  is  an  equivalence  relation. 

Proposition  5.12  Time-triggered  equivalence  is  not  a  congruence  relation. 

Proof:  Consider  the  following  process  specifications: 

P  =  ie,l).{f,l).NIL 
Q  =  (/,l).(e,l).iV/L 
S  =  X  +  {e,2).NIL 

That  P  =„  Q  follows  from  the  definition,  since  they  include  sequences  of  untimed  actions 
that  differ  only  in  the  order  of  events.  But  substitution  of  P  into  5  (5{P/X})  results  in  a 
preemption  of  the  P  sub-process  by  the  (c,  2)  event  of  5  that  will  not  occur  in  the  purely 
nondeterministic  S{Q/X}.  □ 
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The  problems  involved  in  creating  a  time-triggered  congruence  for  full  ACSR  are  more 
severe  than  for  any  of  the  previous  relations.  The  difficulty  arises  from  the  restriction  opera¬ 
tor,  which  can  terminate  a  process  at  any  specified  event  label.  Since  allowing  permutations 
of  event  labels  is  basic  to  time-triggered  equivalence,  and  early  termination  of  permutated 
event  sequences  may  not  produce  the  same  set  of  {label,  priority)  pairs,  there  is  no  meaning¬ 
ful  way  to  reformulate  the  definition  so  that  restriction  will  preserve  congruence.  Instead, 
we  settle  for  congruence  over  sequential  ACSR. 

Definition  5.16  (Partial  Time-Triggered  Congruence:  P  Q  iff,  for  all  a  € 

2>, 

{ij  Whenever  P  S,  P'  then,  for  some  Q',  Q  -5,  Q'  and  P'  =«  Q'. 

(ii)  Whenever  Q  -5,,  Q*  then,  for  some  P\  P  -5,  P*  and  P'  =«  Q*. 

Proposition  5.13  Partial  time-triggered  congruence  is  an  equivalence  relation. 

Proposition  5.14  Partial  time-triggered  congruence  is  a  congruence  relation  over  sequen¬ 
tial  ACSR. 

In  fact,  something  stronger  could  be  proved,  since  restriction  is  the  only  operator  that  must 
be  eliminated  from  full  ACSR  to  allow  a  congruence  to  be  defined. 

5.2.2  IVace  Based  Equivalences 

Definition  5.17  (Traces)  For  an  ACSR  process  P  with  action  domain  V  a  trace  of  P  is 
a  sequence  of  zero  or  more  actions  {01,02,  •  •  *  ,On)  6  that  P  Pi 

Pn.  The  set  of  all  traces  of  P  is  denoted  tr,(P). 

Definition  5.18  (Operators  on  Traces)  For  t  =  (01,02, •••  ,a„)  a  trace  of  an  ACSR 
process,  hd{t)  =  oi  (the  head  oft)  and  tl{t)  =  (02, 03,  •  •  • ,  ocn)  (the  tail  of  t). 

Definition  5.19  (Trace  Equivalence:  =r)  P  —t  Q  iff  tr„{P)  C  tr,(Q)  and  tr,e{Q)  C 

tr.{P) 

Proposition  5.15  Trace  equivalence  is  an  equivalence  relation. 

Proposition  5.16  Trace  equivalence  is  a  congruence  relation  for  full  ACSR. 
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IVace  equivalence  is  defined  in  terms  of  trace  inclusion,  which  is  simply  a  subset  relation 
between  trace  sets.  In  the  spirit  of  the  LTS  based  equivalence  relations  presented  in  Section 
5.2.1,  there  are  other  interesting  equivalence  relations  between  trace  sets  that  can  be  defined 
to  yield  new  trace  based  notions  of  equivalence.  The  first  such  relation  ignores  priority  levels 
on  actions  wd  external  events.  It  is  analogous  to  unprioritized  equivalence. 

Definition  5.20  (Unprioritized  Trace  Inclusion:  Cy)  For  ACSR  processes  P  and  Q, 
trr(P)  Cy  tr,(Q)  iff  for  all  (Q!x,a2,- •  •  ,«n)  €  €  tr^iQ)  such  that 

for  all  i,  l(ai)  —  i(j3i)  (for  events)  or  p{ai)  =  p{0i)  (for  actions). 

Definition  5.21  (Unprioritized  Trace  Equivalence:  jrxy)  P  =Ty  Q  ifftr^{P)  Cy  tr^{Q) 
and  tr^{Q)  Cy  tr^{P) 

In  a  system  with  resources  dedicated  to  each  process,  the  specific  resources  used  by  a 
process  may  be  of  little  interest  when  comparing  alternative  implementations.  The  following 
equivalence  relation  captures  that  notion  by  matching  only  synchronization  actions  and  the 
placement  of  timed  steps,  ignoring  the  resources  consumed  by  timed  steps. 

Definition  5.22  (Resource  Neutral  Trace  Inclusion:  Cy)  For  ACSR  processes  P  and 
Q,  tr^{P)  Q^tr:,{Q)  iff  for  all  (ai,a2,---,an)  €  <r,(P),3(/?i,/32,-’-,/5n)  €  tr^iQ)  such  that 
for  all  i,  l{ai)  =  l{0i)  (for  events)  or  a,-  and  0i  are  actions. 

Definition  5.23  (Resource  Neutral  Trace  Equivalence:  =Ty)  P  Q  iff  Q/ 
<»*ir(Q)  and  <r,(Q)  Cy  tr^{P) 

The  following  equivalence  relation  extends  the  notion  of  r-free  equivalence  to  equivalence 
based  on  traces. 

Definition  5.24  (r-iVee  Equivalence  of  Traces:  =y)  For  traces  s  and  t,  s  =ft  iff 

1.  s  =  {)  and  t  =  (),•  or 

2.  hd{s)  =  hd{t)  and  tl(3)  =yf/(t);  or 
S.  hd{s)  s=  T  and  tl(s)  =y  t;  or 
4.  hd{t)  =  r  and  s  =y  f/(t). 


I 


63 


Definition  5.25  (r-iVee  Ttace  Inclusion:  Cy)  For  ACSR  processes  P  andQ,  tr„(P)  Cy 
iff  for  all  s  6  4r,(P),3t  €  tr,{Q)  such  that  s  =y  t. 


Definition  5.26  (r-iVee  TVace  Equivalence:  =t/)  P  =ty  Q  iff  tr^iP)  Qy  lr„{Q)  and 

tr^iQ)  Qi  lr^{P) 

Although  there  are  many  other  interesting  relations  that  can  be  defined,  we  believe  that 
the  above  ones  are  most  intuitive  and  thus  probably  practical. 

5.3  Logic  for  Communicating  Shared  Resources 

In  this  section,  we  describe  briefly  on  LCSR,  logic  for  communicating  shared  resources.  LCSR 
is  a  temporal  logic  which  is  dedicated  to  ACSR.  LCSR  is  well  suited  for  expressing  properties 
about  temporal  ordering  of  events.  The  temporal  operators  axe  useful  for  specifying  ACSR 
program  behavior.  A  LCSR  formula,  containing  temporal  operators,  is  interpreted  over  a 
structure  of  ACSR  program.  LCSR  is  event  based  zmd  interval  logic.  Hence  the  semantics 
is  based  on  intervals  on  time  in  ACSR  program. 

The  syntax  of  LCSR  is  following: 


E  1  I  c  I  R  I  €*'  I  I  1  V  E2 
F  ::=  truel-^/(£2)Fl-^/{£2}/^h-f’|i^iVF2 


1  stands  for  disjunction  of  all  events  and  adl  2u:tions.  e  is  instantaneous  events  and  R 

pi 

is  time  consuming  actions.  Informally,  — '-*i{E2)F  means  that  for  some  computation  path, 
El  will  occur  contiguously  until,  within  time  /,  event  £2  occurs  at  which  point  F  is  true. 
— ^/{£2}F  means  that  there  is  for  all  computation  paths,  Ey  will  occur  contiguously  until, 
within  time  /,  event  £2  occurs  at  which  point  F  is  true.  Those  two  operators  can  be 
expressed  in  terms  of  TCTL  [1]: 

-^/<e2)£  =»  3eiWj(e2A£) 

-^iMF  ==►  VeiWHejAF) 


The  followings  are  some  interesting  real-time  properites  and  corresponding  LCSR  formu¬ 
las. 
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•  After  the  reaction  process  (denoted  by  the  events  "^beg”,  ""end”)  starts,  it  cannot  be 
interrupted  (denoted  by  the  events  “intBeg”.  ‘‘intEnd”)  for  more  than  12  time  units 
unless  the  reaction  process  stops: 

[beg]  ^^[intBeg]io,i2]{endy  intEnd} 

•  Once  a  job  starts  execution  (denoted  by  “beg"'),  it  will  run  to  completion  (denoted  by 
“end”)  without  missing  deadlind  (denoted  by  “out”): 

[beg]  =^{end^} 

•  Any  sampling  operations  (denoted  by  “s”)  and  injection  operations  (denoted  by  “p”) 
in  the  gas  container  should  be  at  least  7  time  units  apart  from  each  other: 

(W  A  ([p]  — ^(7,7]{1}) 

•  If  the  right  button  has  been  clicked  (denoted  by  “b”  )  for  three  times  within  5  time 
units,  there  will  he  a  menu  poped  up  (denoted  by  “m”  )  within  5  time  units  from  the 
last  click: 


•  Any  interval  of  a  train  passing  the  cross  (denoted  by  “enter”  and  “exit”)  should  be 
contained  strictly  in  an  interval  of  the  gate  being  fully  down  (denoted  by  “down”  and 
“up”),  and  securing  at  least  t  time  units  beyond  each  end: 

[up]  ~'^^^{down^} 

A  [down] 

A  [enter]  •^{exit}[,,oo){«P^} 

1.  There  is  no  train  entering  the  crossing  from  the  gate  being  up  to  being  down; 

2.  There  is  no  treiin  entering  the  crossing  t  time  units  from  the  gate  being  down; 

3.  Once  a  train  enters  the  crossing,  the  gate  will  not  be  up  until  after  t  time  units 
after  it  exits. 
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LCSR  can  naturally  describe  various  desirable  properties  of  a  ACSR  (i.e..  GCSR)  speci¬ 
fication.  The  reasons  for  this  new  logic  is  because  we  could  not  use  RTL  as  our  requirement 
specification  logic  and  other  real-time  (temporal)  logics  does  not  naturally  describe  prop¬ 
erties  of  ACSR  specifications.  We  believe  that  a  LCSR  formula  can  be  efficiently  model 
checked  for  ACSR  specifications. 
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6  Phase  II  Implementation  Plan 


One  goal  of  Phase  I  is  to  evaluate  existing  graphical  specification  systems  to  check  whether 
they  can  be  used  in  implementing  the  toolkit  environment.  In  Section  2.2  and  Section 
2.3,  Modechart  was  evaluated  and  compared  with  ACSR.  It  was  shown  that  ACSR  terms 
can  be  translated  into  Modechart  by  extending  the  graphical  specification  language.  Also, 
GCSR,  a  graphical  specification  language  for  ACSR,  was  defined  in  Section  3.  It  follows 
that  MCTool,  a  graphical  specification  system  based  on  Modechart,  can  be  extended  to  be 
a  graphical  front-end  of  the  toolkit  environment.  On  the  other  hand,  analysis  tools  of  the 
toolkit  environment  can  be  implemented  by  reusing  source  code  from  VERSA,  aji  ACSR- 
based  tool  for  the  algebraic  analysis  of  real-time  systems  [7]. 

The  overall  structure  of  the  toolkit  environment  is  discussed  in  Section  6.1.  The  im¬ 
plementation  plan  of  reusing  and  extending  MCTool  and  VERSA  are  presented  in  Section 
6.2. 


6.1  The  Overall  Structure  of  the  Toolkit  Environment 

A  high  level  view  of  the  toolkit  environment  is  presented  in  Figure  24. 

The  environment  has  a  main  menu  window  which  contains  commands  of  opening  a  spec¬ 
ification,  creating  a  specification  and  terminating  the  environment.  Once  a  user  opens  or 
creates  a  specification,  a  menu  window  for  the  specification  appears.  The  menu  window 
contains  commands  that  apply  to  a  specification  as  a  whole.  The  commands  include  saving, 
reverting  to  a  saved  specification,  printing,  closing  and  performing  analysis.  A  user  creates, 
views  and  modifies  a  GCSR  specification  using  a  graphics  editor.  It  has  icons  of  nodes  and 
edges  of  a  GCSR  graph.  A  user  creates  a  graphical  object  by  clicking  one  of  the  icons.  Then 
he  annotates  the  created  object  using  a  corresponding  template  for  its  attributes.  Also,  he 
can  manipulate  graphical  objects  by  copying,  deleting,  pasting,  aligning,  enlarging,  shrink¬ 
ing,  etc.  A  GCSR  specification  of  a  large-scale  system  cam  be  represented  by  a  set  of  graphs 
and  their  hierarchy.  A  user  can  view  the  specification  by  scrolling  the  windows  and  navigat¬ 
ing  the  hierarchy  of  the  graphs.  The  graphics  editor  provides  a  navigation  map  for  traversing 
the  whole  specification  expressed  in  GCSR. 

A  GCSR  specification  can  be  converted  automatically  to  an  ACSR  specification  that  can 
also  be  automatically  translated  to  the  CSR  state  machine  for  analysis.  Once  a  specification 
has  been  converted  to  the  CSR  state  matchine.  the  ainadyst  may  execute  the  specification  and 
test  it  to  determine  its  reasonableness.  The  amaJyst  may  then  apply  optional  state  mini- 
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mization  algorithms  to  the  specification.  Though  the  effectiveness  of  state  minimization  will 
vary,  successful  application  of  this  process  can  significantly  reduce  the  computing  resources 
required  by  later  analysis  ph«ises. 

Analysis  of  the  CSR  state  machine  will  be  carried  out  using  four  basic  analysis  tools. 
The  first  analysis  tool  is  a  simulation  tool  that  demonstrates  operational  behaviors  of  a 
specification  by  executing  the  CSR  state  machine.  The  GCSR  graphs  of  the  specification 
being  simulated  are  used  as  a  graphical  user  interface.  The  analyst  uses  the  GCSR  graphs  as 
input  ports  for  entering  simulation  parameters.  The  results  from  the  simulation  are  displayed 
through  the  graphs. 

The  second  analysis  tool  is  a  model  checking  tool  that  will  allow  the  GCSR  specification 
to  be  tested  against  LCSR  propositions.  LCSR  propositions  can  be  formulated  to  assert  the 
truth  or  falsity  of  various  properties  of  the  system,  and  the  model  checking  algorithms  can 
be  used  to  verify  whether  the  CSR  state  machine  (and  consequently  the  GCSR  specification 
modeled),  satisfies  the  given  property. 

The  third  analysis  tool  is  a  state  exploration  tool  that  can  be  used  to  generate  valid 
traces  of  actions  for  the  system  being  analyzed.  For  finite  systems  it  will  be  possible  to 
examine  all  valid  traces  of  the  system  in  question.  For  both  finite  and  infinite  systems  the 
state  exploration  tool  will  allow  interactive  exploration  of  traces,  the  selective  enumeration 
of  subtraces,  generation  of  all  traces  of  a  given  finite  length,  and  generation  of  fixed  length 
traces  on  the  basis  of  random  selection,  or  statistical  weights  of  alternatives. 

The  fourth  analysis  tool  will  test  for  equivalence  between  two  or  more  alternative  GCSR 
specifications.  The  type  of  equivalence  verified  may  be  relatively  crude,  such  as  trace  equiva¬ 
lence,  or  it  may  be  a  more  sophisticated  equivalence,  such  as  weak  bisimulation  as  described 
in  Section  5.2.  For  models  that  incorporate  probability  weights  to  characterize  nondetermin¬ 
ism,  the  analyst  can  use  probabilistic  bisimulation. 

6.2  Implementation 

The  toolkit  environment  will  be  implemented  in  C-i-f  and  Unix/X  windows  environment. 
The  source  code  of  MCTool  and  VERSA  can  be  reused  during  the  implementation. 

The  graphical  user  interface  of  the  toolkit  environment  can  be  implemented  by  reusing 
the  source  code  of  MCTool;  The  main  menu  window  can  be  constructed  by  reusing  the  main 
window  of  MCTool.  The  Specification  window  of  MCTool  can  be  used  for  implementing  the 
specification  menu  window  of  the  environment. 

The  graphics  editor  of  the  environment  will  be  implemented  by  extending  the  Work 
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Figure  25;  Work  Window:  the  HARM  missile  example 
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window  of  MCTool.  New  icons  for  the  NIL  node,  the  Dot  node,  the  Recursion  node,  the 
Reference  node,  the  External  Exit  edge,  and  the  Internal  Exit  edge  should  be  added  as 
to  the  Work  window  as  shown  in  Figure  25.  The  templates  of  the  nodes  and  the  edges 
must  be  created  so  that  a  user  can  enter  and  update  the  values  of  the  attributes  of  the 
associated  graphical  objects.  Figure  25  illustrates  a  sample  Work  window  which  contains 
the  HARM  missile  example  in  GCSR.  The  navigation  map  of  the  graphics  editor  will  be 
implemented  by  reusing  the  Locator  window  of  MCTool.  The  Locator  window  displays  the 
entire  specification.  A  Work  window  indicator  of  the  Locator  window  denotes  the  portion 
of  a  specification  displayed  in  the  Work  window.  The  indicator  is  used  in  rapid  navigation 
around  specification.  The  indicator  can  be  dragged  and  resized. 

The  current  version  of  VERSA  has  tools  for  algebraic  rewriting,  equivalence  testing  (for 
strong  and  weak  bisimulation)  and  interactive  execution  [7].  The  algebraic  rewriting  tool  and 
equivalence  testing  tool  can  be  reused  for  the  toolkit  environment.  The  interactive  execution 
tool  can  be  extended  to  be  the  GCSR  simulator  of  the  environment,  VERSA  is  now  being 
extended  by  augmenting  tools  of  model  checking  amd  state  exploration.  Those  tools  can  also 
be  reused  for  the  toolkit  environment. 
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